Re: [boost] [filesystem] revised function to determine availablefile system space

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-09-14 20:55:59

"Rob Stewart" <stewart_at_[hidden]> wrote in message 
news:200509131320.j8DDKJ8K031913_at_shannonhoon.balstatdev.susq.com...
> From: "Beman Dawes" <bdawes_at_[hidden]>
>>
>> I'm planning to add a filesystem function to determine available disk 
>> space.
>
> Great!
>
>> Perhaps something like:
>>
>> struct space
>> {
>>   boost::uintmax_t  available;  // bytes available to user
>>   boost::uintmax_t  total;        // total bytes on volume
>> };
>>
>> space filesystem_space( const path & p );
>
> As previously mentioned, the "filesystem_" prefix is redundant.

Yep. The implementation (committed to CVS branch i18n yesterday)  uses 
space().

> Also, I wonder about the value of returning both values
> simultaneously.  I don't expect that all platforms, if any do,
> provide both values in a single API call.  Thus, your one call
> would frequently result in multiple API calls, in my
> imagination.  I'll grant you that your function wouldn't be
> called with high frequency, so that's not too much of a concern.
>
> I propose this interface:
>
>   boost::uintmax_t free_space(path const &);
>   boost::uintmax_t capacity(path const &);

Interesting. Windows and POSIX supply the result via a single call. But 
other systems might have separate calls. Separate functions are a bit easier 
to specify.

> That leaves open the possibility of additional queries in the
> future without having to change the return type.  Also, the
> return type could grow too large to like returning it by value,
> so you might wind up changing the interface altogether when the
> space type grows too large.

Excellent points.

> Another approach is to create a device type that can provide
> member functions to query a variety of attributes.  There could
> even be a hierarchy of types.  Since this kind of information
> isn't queried with high frequency, there shouldn't be any
> complaints about virtual functions, for example.
>
> The hierarchy would permit derivates to encapsulate the logic
> that no doubt differs for the various devices one would like to
> query.  Windows probably uses a different API for every kind of
> device, for example.
>
> So, I'm thinking of something like the following list of types:
>
>   device
>   disk : device
>      hard_disk : disk
>      floppy_disk : disk
>      network_disk : disk
>   usb_drive : device
>   pccard : device
>   etc.
>
> Whether all of those (or any, for that matter) are needed is
> debatable.

While we've often talked about a more flexible way to deal with attributes, 
particularly operating system specific attributes, I've not yet been 
convince any proposed scheme is worth the effort.

I'll give your suggestion regarding separate free_space() and capacity() 
functions some more thought tomorrow morning when my mind is functioning a 
bit better than it does at night (Of all the things I've ever lost, I miss 
my mind the most:-)

--Beman