BOOL GetDiskFreeSpace(
LPCTSTR lpRootPathName, ' pointer to root path
LPDWORD lpSectorsPerCluster, ' pointer to sectors per cluster
LPDWORD lpBytesPerSector, ' pointer to bytes per sector
LPDWORD lpNumberOfFreeClusters, ' pointer to number of free clusters
LPDWORD lpTotalNumberOfClusters ' pointer to total number of clusters
);
If you don't know how to use this call, let me know. I am curious WHY YOU want to know!
If you aren't a C++ coder here's the allapi VB version:
Code:
'In general section
Private Declare Function GetDiskFreeSpace Lib "kernel32" Alias "GetDiskFreeSpaceA" (ByVal lpRootPathName As String, lpSectorsPerCluster As Long, lpBytesPerSector As Long, lpNumberOfFreeClusters As Long, lpTtoalNumberOfClusters As Long) As Long
Private Sub Form_Load()
'KPD-Team 1998
'URL: http://www.allapi.net/
'E-Mail: [email protected]
Dim Sectors as Long,Bytes as Long,FreeC as Long, TotalC as Long,Total as Long,Freeb as Long
'Retrieve information about the C:\
GetDiskFreeSpace "C:\", Sectors, Bytes, Freec, Totalc
'Set graphic mode to persistent
Me.AutoRedraw = True
'Print the information to the form
Me.Print " Path: C:\"
Me.Print " Sectors per Cluster:" + Str$(Sector)
Me.Print " Bytes per sector:" + Str$(Bytes)
Me.Print " Number Of Free Clusters:" + Str$(Freec)
Me.Print " Total Number Of Clusters:" + Str$(Totalc)
Total = rTotalc& * rSector& * rBytes&
Me.Print " Total number of bytes in path:" + Str$(Total)
Freeb = rFreec& * rSector& * rBytes&
Me.Print " Free bytes:" + Str$(Freeb)
End sub
Billow noticed that his call to GetDiskFreeSpace was producing invalid results. He was doing the call correctly. The issue here is that GetDiskFreeSpace produces unpredicable results with large hard drive. Microsoft's replacement is GetDiskFreeSpaceEx. But guess, what. This new call does not tell you the BytesPerSector or the SectorsPerCluster. There is one solution. Listen up.
You have to make call Int 21h Function 7303h Get_ExtFreeSpace. It appears that you can do this starting with Windows OEM Service Release 2 - if not, call GetDiskFreeSpace.
Now, you can call this Function from assembly code or from C - but not directly from VB (as far as I know). However, you can also call it from VWIN32 (which is a VXD).
Windows knows file size and the size of a cluster. You cannot put a file in less than one allocation unit - be it 20 times the size of the file. This is how Windows allocates disk space.
Just because a file is one byte long, doesn't mean it only uses one byte of disk space. It uses one allocation unit. This is true for many OS's, not just Windows.
In essence the call IS responding correctly.
If you don't believe me, try:
GetDiskSpace
open a file , write 1-2 bytes to the disk
close the file
GetDiskSpace
First of all jim mcnamara, I don't think that anyone is suggesting that this is an anomaly - although Billow does seem to think it's novel.
You are correct, and we all agree, that disk consumption is in increments of "allocation units".
Actually, this 'action' exists, even without Windows. The smallest unit of allocation on a disk is a sector. Once the OS's File System comes into play (DOS or Windows), sectors are grouped into clusters (or "allocation units") which can be at SMALLEST, one disk sector.
WHAT I AM SAYING, and which IS correct, is that the API call GetDiskFreeSpace can return INVALID results. I, and Billow, have observed invalid returns for lpSectorsPerCluster.
Additionally, I have observed invalid returns for lpNumberOfFreeClusters and lpTotalNumberOfClusters . MS is highly aware of this.
Apparently, disks larger than 2MB can cause this effect. Thus, Microsoft created the call GetDiskFreeSpaceEx which deals with 64-bit values instead of 32-bit.
However, the problem with this call (GetDiskFreeSpaceEx) is that it DOES NOT return lpSectorsPerCluster and lpBytesPerSector. These are the numbers you multiply together to determine the OS's "allocation unit" size - these are the numbers Billows wants.
This is Billows issue, and like I said, a good one. Billow, go ahead with my suggestion as previous EXCEPT note that some reports have been made about Get_ExtFreeSpace returning bad values when more than one HD is installed. Use Get_ExtDPB instead. :-)
Last edited by Jay Rogozinsky; Aug 11th, 2001 at 12:34 AM.
I got it!
But it's difficult for me to use Assembly from C as I'm a Pure VB programmmer .
Even I find it hard to call it from VXD,But I believe you can manage it.
Now I'm writing a routine myself to get the allocation unit size .
it's simple and very easy to understand.
and it works well in both 9x/2000 System.
it also supports Multi-Harddisks , even their size is larger than 2 GB!
I looked at the code and I understand your approach. Although it is likelly that it may produce correct results a good portion of the time - I would probably not go with this solution.
There are even third party utilites people can easily get access to which allow them to change the drive dynamics from any sort of likelly standard.
I came up with several other ideas. One of these was to check the drive free space, create a 1-byte file, and check the free space again. Of course this would have to be done several times as other programs may introduce complications. I would not even go with this solution myself.
I will write something up and have it posted soon. You might like it better.
From this code you will see that making the VXD call is simpler than you thought. First, it checks to see if Win95B or greater is running. If it is, it calls the VXD. If it is not, it calls GetDiskFreeSpace. You should do some testing to make sure it's operating at 100%.
I have ZIPPED together a Form and a Module. I Hope you have WinZip or whatever to extract them.
It took a bit of effort - I wouldn't mind some credit in your program :-)
I've downloaded the routine,and I run it.
Thank you very much.
It's the right one that I've long been looking for.
You really Help me ! This routine will contribute a lot to my project that I once refered to.
You are a Pofessional Programmer,I Believe.
So there is a lot of things I should Learn from you.
you must know GUID,Global Unique Identification.
once it's used in shellexecute api with the option of "/root",it will browse the GUID Directory with root. that is to say.when browsing. the back,up,...button is disabled.
You can only browse the guid directory.
I have obtained the GUID of RecylceBin.
BUt the temp,recent,cache,cookies,history,download program files ...they really confuse me a lot.
If you know the guid of these directories,would you please post it?
thank you very much.
A chinese Hard-Working student
I knew while I was developing that code that there was some unresolved issues.
The call to Get_ExtDPB utilizes a buffer, organized as a DPB structure, to retrieve information into. Unfortunatelly in this case, VB pads the DPB structure - thus making the structure incompatible (unaligned) with the data in the buffer written to by Get_ExtDPB.
I noticed this during the testing as interesting values retuned by some of the members of DPB. I have since adjusted the Get_ExtDPB code to compensate for the "misalignment".
(Really, what is introduced by this issue is the lose of ease of using the DPB structures members directly, by name.)
Wth the code adjusted, some values are better while others still appear "interesting". (I am investiagting further.)
(If you remember, I chose Get_ExtDPB over Get_ExtFreeSpace because of a comment I read in some mail thread.)
A fact about Get_ExtDPB is that it requires a Drive specification by NUMBER. On the other hand, both the 'old' GetDiskFreeSpace call and the other IOControl call Get_ExtFreeSpace allow Drive specification by NAME.
At this point in my investigation I decided to try the other IOControl call Get_ExtFreeSpace - after all it takes Drives by NAME, and, the only reason I chose not to at first was one comment in a mail thread somewhere.
So, I built the call to Get_ExtFreeSpace. It TO uses a buffer which is organized as a structure. However, this structure's members are all Long, and as such, VB does not padd the structure - so it remains aligned with the buffer.
Get_ExtFreeSpace seems to be running well. All the return values are not "interesting" and they contain valid data.
So, I guess, to alleviate any known concerns with Get_ExtFreeSpace it must be run on a multi-drive system. I haven't had the time to do so.
I've had the altered code for some time, sorry for the delay in posting it here.
You will have to test it on a multi-drive system to be sure it's gonna work - read my previous message here.
Get_ExtFreeSpace returns the numbers you want - SectorSize and SectorsPerCluster. Also, be aware the Get_ExtFreeSpace returns numbers for Free and Total "clusters" AND "allocation units". These are the same numbers on my system - I suspect they are different on systems that use drive compression.
Although I have found a way to repair the Get_ExtDPB call, and it appears to be returniong good results, I have commented out it's call and replaced it with Get_ExtFreeSpace.
I ask that you apprise me (and the forum) of your test results.
I'm now downloading the code and I will test and run it as soon as possible and send you the result.
Thank you for your continuing efforts.I really appreciate it.
But,Jay,you know,Due to my poor knowledge,I don't understand the assembly call you've written clearly. How do you know these sophisticated knowledge? Is there any good book that I can come up with these knowledge?
I suppose you are a professional VC or Assembly Programmer meanwhile.
I will send you the result as soon as possible,just wait.Thank you.
Reply With Quote