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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-13 08:20:19

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.
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 &);

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.

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.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;