>>But how are you going to actually change the file system? You can't merely specify a cluster size for a single file. It's a disk wide change and cannot be easily controlled.
>
>I don't want to change anything. All I want to do, with my utility, is report how much space is used. Let's say it is obvious to the user that his cluster size is, e.g., 4 KB, but the program shows information based on 32 KB clusters (because of the FAT32 problem, or because of a network connection), the user can change from "Auto-detect" (the default) to "4 KB".

Use GetDiskFreeSpaceEx() then. That will correctly return the amount of free space on the drive regardless of cluster size.

>Also, if the user gets information for a folder on a local NTFS partition (say, 4 KB clusters) and wants to know how much space the files would use on a FAT32 partition of 20 GB (16 KB clusters, if formatted without the "/Z:nn" option), the user can change the auto-detected 4 KB to 16 KB.
>
>>You're not going to find anything better. Networked drives are extremely problematical at best, and you've no way of interfacing with the network OS. Each user has an allocation, however, and that's what's reported as free space. As long as there are no pending writes in the cache, you should be OK. However, pending writes do pose a problem, since there's no way to control when the buffers get flushed.
>
>Why, I would at least expect to get reliable information from a local drive! Which perhaps I can't, with FAT 32.
>
>>It could be. However, be aware that VFP 6.0 cannot through its internal functions get the correctly amount of free or total disk space when these values exceed 2 gb. The reason for this is that it's accessing the GetDiskFreeSpace() function. In order to return the correct amount, the programmer has to access GetDiskFreeSpaceEx(). I've an FAQ here that explains how to do this. Additionally, there's no way to accurately return the information prior to Win95 OSR2 since GetDiskFreeSpaceEx() wasn't available prior to that release. Determining whether or not the function is available is shown in the FAQ.
>
>Can this function (...Ex()) also get the cluster size?

No. Read the FAQ

>>No there isn't. If I recall correctly, information regarding the cluster size is stored by the ROM BIOS. Windows probably loads this information on startup. There's no way via the API to interface with the ROM BIOS interrupt functions to retrieve this information.
>
>This sounds doubtful to me, since the ROM BIOS is, by definition, ROM, therefore, read/only. Not changable. Hard disks, however, can change. And the ROM BIOS isn't exactly stored on the hard disk.

I'm not 100% percent certain that cluster size is stored by the ROM BIOS. It may be, but it's been a long time since I did anything serious with ROM BIOS interrupt calls. Yes, it is ROM but the information isn't stored in ROM (of course), it's simply accessed through the ROM BIOS. How do you think a computer knows what time it is? Whether or not Plug-and-Play is enabled? Where do you think the keyboard repeat rate is stored and how are these things are changed and modified. Through the ROM BIOS. When your battery on the computer goes "bye-bye" you lose all these settings.