Re: [boost] [filesystem] revised function todetermineavailablefile system space

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-09-16 16:33:43

"Greer, Joe" <jgreer_at_[hidden]> wrote in message 
news:4513FB40A0DFFA418689E402B74043CF8EFC30_at_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