On 16/09/05, Ben Hutchings
1. The existence of quotas that limit disk usage further 2. Overheads for file metadata 3. Other concurrent processes using or freeing space on the volume 4. Resizing of the volume
I think simply having the structure contain free, used, and total space can take into account 1 quite easily, so long as we don't specify free+used=total, which would make one of them extraneous in any case. Total could of course also be dropped entirely, since I can't think of a use case where used and free wouldn't be sufficient ( especially since any total space above free+used would logically be inaccessible anyways ). As for point 2, including a function for "how much space is the tree rooted at this path" would take into account that already, which could be useful as a quick sanity check before beginning a large copy operation, for example. This information is also often a nice convenience for users of a program, especially in the case of the possibility of writing to USB flash drives, for example, in a music program. 3 is not an issue to be overly concerned about. As with the rest of the library, the function would simply make no assurances. There is the precedent for functions like this though, such as is_symbolic_link. I also don't think 4 would be an issue, because it's rare that a volume can be resized while still being writable. Additionally it's not a common operation and anyone with the knowledge to do it should have the knowledge to not be surprised about temporarily odd measurements. One important issue, however, is that there is a need for listing which directories are their own roots, or at least figuring out if 2 directories are part of the same tree. Single-root operating systems will often have a vastly different amount of free space on /mnt/ and /mnt/cdrom/ if a CD is mounted there. ( Which raises another race condition possibility. ) - Scott McMurray