From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-09-13 06:42:58
"Thomas Matelich" <matelich_at_[hidden]> wrote in message
> On 9/12/05, Beman Dawes <bdawes_at_[hidden]> wrote:
>> I'm planning to add a filesystem function to determine available disk
>> 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 );
> Seems like a perfectly usable API.
> How safe is the assumption that uintmax_t is large enough nowadays for any
>> modern compiler on a system supporting large disks.
> Well, you need 50 bits for a petabyte, I don't think people are
> using/exceeding that much these days, so platforms supporting long long
> should keep you in space for few years. I'd think you'll find the answer
> that as you write platform specific versions. As long as uintmax_t is
> than the parameter to the function, you'll be sitting pretty.
> I suppose a platform supporting insane amounts of diskspace could report
> with a low-longlong and hi-longlong, but I'm sure we'll be able to ifdef
> apm_unsigned by then.
I've now looked at the config_info results for every compiler reported in
the Boost regression tests. All support a 64-bit type, so we are home free
>> Better suggestions for the names?
> I think filesystem::filesystem_space is a bit redundant. If we want to be
> forward looking we should avoid the word disk since flash HD's are
> a reality. This information will return free space on the partition path
> lives on. Unix often calls partitions volumes. I'm not really
> myself into any great names.
> space usage(path const&); //kinda like it
> drive_space drive_usage(path const&); //bad - not info for the whole drive
> volume_info stats(path const&); //bad - too confusing with stat
> Oh well, whatever the name, it'll be a good addition.
space_info space((path const&);
Thanks for the feedback; I'll go ahead and implement something.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk