"Thomas Matelich" <matelich@gmail.com> wrote in message news:3944d458050912191464699fcb@mail.gmail.com...
On 9/12/05, Beman Dawes <bdawes@acm.org> wrote:
I'm planning to add a filesystem function to determine available disk space. 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 );
Comments?
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 to that as you write platform specific versions. As long as uintmax_t is larger 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 with uintmax_t.
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 becoming a reality. This information will return free space on the partition path lives on. Unix often calls partitions volumes. I'm not really brainstorming 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.
Or maybe: space_info space((path const&); Thanks for the feedback; I'll go ahead and implement something. --Beman