"Greer, Joe" <jgreer@nsisoftware.com> wrote in message news:4513FB40A0DFFA418689E402B74043CF8EFC30@MAIL-IN02.nsisw.com...
In looking at this a bit further, both POSIX and windows distinguish between total free space and free space available "to nonprivileged process" (POSIX) or "to caller" (Windows).
To accommodate this, we might have:
boost::uintmax_t capacity(path const &); boost::uintmax_t total_free_space(path const &); boost::uintmax_t available_free_space(path const &);
IMO, total_free_space() and available_free_space() should be tied together so that you can make some relationship between them. If they are implemented as separate calls, then you don't really know what disk activity went on between the first and second calls. I can see a case where the total_free_space might be < than the available_free_space if you called the functions in the wrong order and there was disk activity going on.
It doesn't seem possible to avoid race conditions. Even if total_free_space and available_free_space are tied, the actual ground-truth values may change the moment the call returns. Someone else described these values as basically just hints, and that's all they really are if more that one task, process, or computer is modifying the filesystem. --Beman