I’ve tried googling this, but these days you get directed to sites that hide the information unless you join, and a lot of other sites that answer a different question.
I have run treesize on my dad’s PC and it reports 22GB used space (similar ‘allocated’)
but when you right click on c: in windows explorer it shows 40gb used. This seems too large a difference to be accounted for by the usual ‘reasons’ for size discrepancies.
So how accurate is windows drive properties supposed to be?
And any advice on how to diagnose why there is such a discrepancy if there shouldn’t be?
To make matters more confusing, on another PC, treesize reports 29gb used, but the drive properties reports 24. So the discrepancy is reversed.
Further to this, if I select all folders on c (including root files) on the drive that claims to be 40gb full and then click properties, the total comes to about 16gb. (hidden and system files are shown)
Every file on your hard drive is allocated space in blocks. Let’s say the blocks size is 2048 bytes. If you have a file called TEST.TXT with only one byte in it, it still takes 2048 bytes on the disk. So any given file will waste between 0 and 2047 bytes on the hard drive.
So there are two ways to ask the question, how many total bytes to my files take, and how much total allocated space do my files take?
For that big of a difference I would trust Windows over a third-party program. I have a program called WinDirStat (very entertaining by the way) and it reports the same free space number that Windows does.
Are you looking at what XP reports as the “size”, or the “size on disk”? For the reasons provided by control-z, these aren’t the same thing, even if you aren’t using filesystem level compression.
From the documentation on treesize’s web page:
This provides several explanations for why it reports a smaller size than does the Windows API. There is also a subtle difference between the amount of free space available vs. the size of the partition minus the allocated clusters, due to file system overhead. The file allocation table and boot sector are only part of this.
Secondly, even administrators don’t have access to all files in the filesystem. The Sysvol directory (previously mentioned) is one of them. This directory is nomrally only readable by the SYSTEM “account” (technically, it’s a “built-in security principle”, but functionally it’s the same thing). To account for that, you would need to run TreeSize under SYSTEM credentials. This is certainly possible, but it’s a pain to set up, and it’s really not very safe. I don’t recommend doing it, especially not with random freeware/shareware utilities.
Finally, I can think of two more reason that you could see a significant difference between the size of all allocated files and the amount of free space reported by the filesystem.
One is NTFS Alternate Data Streams (ADS). Alternate data streams are … weird. They take up space on the drive, but neither their size nor even their presence is reported by Windows Explorer, or any other built-in windows utility. There is a utility called “streams” that was created by Sysinternals (now part of Microsoft) that you can download here. It can scan your hard drive for ADSs if you want to rule out that possibility.
The second possibility are rootkits. Malicious code running at kernel level can hook the standard file and registry access API functions like OpenFile and ReadKey in such way that they can selectively hide the existence of files and registry keys from any software that uses the win32/64 API. In fact, they can even hook it at the “native” API (ntdll.dll) level and hide them even from other kernel-level components as well as “userland” code. Detecting this behavior is tricky, but in most cases, dumping the filesystem and registry structures and then parsing through them yourself (instead of using the APIs) will reveal all files and registry keys present on the system. If this doesn’t match the answers you get from the windows API, you have good reason to believe that something in kernel mode is hiding files from you. Sysinternals comes to the rescue again with a utility called Rootkit Revealer, which does exactly this.
It sounds to me like this is just a case of a utility that uses a fairly pointless metric for free space calculations rather than anything sinister involving ADS or rootkits, but it’s not a bad idea to run either tool just to see what turns up. My first suggestion would be to get a good disk space analyzer and see what numbers you get. I highly recommend the open-source Windirstat utility previously mentioned. If you see a large discrepancy between reported free space and the amount of free space calculated from allocated file space (not raw file size), then I would seriously consider running Streams and Rootkit Revealer.