__int64 i64FreeBytes
unsigned __int64 lpFreeBytesAvailableToCaller,
lpTotalNumberOfBytes,
lpTotalNumberOfFreeBytes; // variables used to obtain
// the free space on the drive
GetDiskFreeSpaceEx (Manager.capDir,
(PULARGE_INTEGER)&lpFreeBytesAvailableToCaller,
(PULARGE_INTEGER)&lpTotalNumberOfBytes,
(PULARGE_INTEGER)&lpTotalNumberOfFreeBytes);
i64FreeBytes = lpTotalNumberOfFreeBytes;
_tprintf(_T ("Number of bytes free on the drive:%I64u \n"),
lpTotalNumberOfFreeBytes);
I am working on a data management routine which is a Windows CE command line application. The above code shows how I get the number of free bytes on a particular drive which contains the folder Manager.capdir (it is the variable containing the full path name of the directory).
My question is, the number of free bytes reported by the above code (the _tprintf statement) doesn't match with the number of free bytes of the drive (which i check by doing a right click on the drive).
I wish to know if the reason for this difference?
Quoting (with editing) the documentation for GetDiskFreeSpaceEx, emphasis mine:
In other words, this number depends on the user, and if you want to match the value returned by Explorer, use
lpFreeBytesAvailable
.I have a single-user machine with no disk quota in operation. I posted your code into a dialog based MFC application and ran it, with the single proviso that I used "C:\" as the lpDirectoryName parameter so I could compare against the drive free space as reported by the system. That seemed logical as free space is only meaningful for a drive, not a folder.
At first I thought that I was seeing a similar problem, but then I re-ran the check (I tied it to a button), and got the same result as the properties dialog at that moment. It seems the free space on a drive is a fairly dynamic quantity - this is not terribly suprising if it is the system drive - and even absent the criteria that other posters have quite correctly reported, you may not see precisely the same number as the properties dialog reports at the moment it was run.
One possibility come to mind. perhaps one is not taking into account space lost to partitioning (windows typically leaves 8MB at the end of the drive as slack). Basically, there is a difference between the space left on the physical drive and the logical one represented by the partition. Or space lost to the filesystem itself.
I couldn't say if these are actually the case, but I'd look into it.