views:

458

answers:

4
__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?

A: 

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.

Evan Teran
A: 

one word: quotas

Here's a nice post about it.

Stefan
-1, link is about Windows not Windows CE. Different products, and the latter doesn't do quotas (since quotas require NTFS)
MSalters
Windows CE can deal with NTFS (depending on which modules are compiled in with the platform builder). Never forget that WinCE is highly configurable by OEMs - there is no single "Windows CE".
Stefan
Windows CE does *not* do NTFS (unless you wrote an NTFS driver, which is far from trivial). Even then you wouldn't magically get quotas. There is no concept of a user.
ctacke
+1  A: 

Quoting (with editing) the documentation for GetDiskFreeSpaceEx, emphasis mine:

lpFreeBytesAvailable [out, optional]-

A pointer to a variable that receives the total number of free bytes on a disk that are available to the user who is associated with the calling thread.

This parameter can be NULL.

If per-user quotas are being used, this value may be less than the total number of free bytes on a disk.

lpTotalNumberOfBytes [out, optional]-

A pointer to a variable that receives the total number of bytes on a disk that are available to the user who is associated with the calling thread.

This parameter can be NULL.

If per-user quotas are being used, this value may be less than the total number of bytes on a disk.

To determine the total number of bytes on a disk or volume, use IOCTL_DISK_GET_LENGTH_INFO.

In other words, this number depends on the user, and if you want to match the value returned by Explorer, use lpFreeBytesAvailable.

MSN
A: 

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 though 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.

Bob Moore