I found this article via Raymond Chen’s blog: NTFS Misreports Free Space?. It’s very interesting (if you like getting to the bottom of technical things). Incidentally it reminded me of an old question I always had:

Why don’t processes which need to read all the files from a given volume (for example AV scanners) use the occupied size to estimate the percent done of the process. Something like this: get the number of bytes occupied on the volume (for example by doing total bytes – free bytes). Now start processing the files one by one, maintaining a sum (using a 64 bit counter) of the processed file sizes. Calculate the percent processed by doing (processed size / total size) * 100. Of course there can be caveats (like files being deleted / created during the process), which you should account for, but in general (IMHO) showing an approximate estimation is better than showing no estimation…

A related problem I was thinking about was “how to find the number of files in a directory without actually enumerating them?”. The problem got resolved an other way in the meantime, however here are some starting points which I’ve found (supposing an NTFS FS on the volume):

There is a FSCTL_GET_NTFS_FILE_RECORD control code for DeviceIoControl. This returns a NTFS_FILE_RECORD_OUTPUT_BUFFER structure which is sparsely documented, however according to “Windows NT(2000) Native API Reference” (search with your favorite search engine to find a PDF of it), you should be able get somehow the DIRECTORY_INDEX structure, from where (probably) finding out the number of entries (which can be either files or directories!) is as simple as dividing the AllocatedSize field by sizeof(DIRECTORY_ENTRY).