>>>The only reliable way to do it across all Win32 platform and file systems is to write get the amount of free space, write a small temporary file, and get the amount of free space afterwards.
>>
>>I disagree: this is not reliable. Another user or process may increase or decrease the free disk space in the meantime. Unless I create a thousand small temp files, and round to the nearest power of 2...
>>
>Disclaimer: I consider George Tasker to be technically reliable, and a reasonably good friend even though we've never met face to face, so I'm not completely unbiased.

I agree; I have seen many of George's comments. The last thing I want to do is to insult him, and I hope my disagreement isn't taken as such.

>Let me suggest you trust George; his recommendation of the API is spot on, and his recommendation on writing a small file and checking it's actual disk space consumption is dead on, too; with NTFS, or FAT systems with DriveSpace installed, you have the issues of sub-cluster file space allocation and automatic compression. In RAID arrays, the unit of allocation is most likely a multiple of the base space allocation unit (min NTFS partition cluster size) * (number of RAID spindles - 1) is common if NTFS compression is not used, and OBTW, compression and sub-cluster allocation is controlled at the file or folder level so the rules aren't consistent. The API call will return the correct base space allocation unit of the logical volume.

Well, I had forgotten about some of these details. Especially, I was aware of "variable cluster size" in the case of DriveSpace and similar, but I didn't work with it for a long time. In this case, the basic "cluster size" can be taken as 512 bytes, I believe, because the "variable cluster size" is a multiple of this.

The real problem (for calculations) is data compression - summing file sizes can give you a maximum size, but the real space used will usually be less.

With RAID, I think you were referring to RAID level 5, right?

>
>Maybe familiarizing yourself with Windows internals would be a worthwhile thing to work towards.

I think I know most of the concepts you explained, but I was mainly considering a "standard" disk - one without compression. However, if it isn't too much trouble, can you briefly explain how "sub-cluster allocation" works in NTFS? Would several small files share a cluster? I had this suspition a while ago, when looking at the actual disk space used, as reported by Windows NT.

Hilmar.