# Is windows XP drive properites accurate?
**URL:** https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250
**Category:** Factual Questions
**Created:** [August 30, 2009, 12:26pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250 "2009-08-30T12:26:19Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Lobsang](https://boards.straightdope.com/u/Lobsang)
#### Post date: [August 30, 2009, 12:26pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/1 "2009-08-30T12:26:19Z")
Hi.
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.
---
### Author:  [@Lobsang](https://boards.straightdope.com/u/Lobsang)
#### Post date: [August 30, 2009, 12:56pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/2 "2009-08-30T12:56:42Z")
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)
---
### Author:  [@Quartz](https://boards.straightdope.com/u/Quartz)
#### Post date: [August 30, 2009, 2:54pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/3 "2009-08-30T14:54:14Z")
Try running Treesize as an administrator. Likely it’s missing the System Volume Information directory, which holds your restore points.
---
### Author:  [@Lobsang](https://boards.straightdope.com/u/Lobsang)
#### Post date: [August 30, 2009, 5:32pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/4 "2009-08-30T17:32:46Z")
> [@Quartz](#):
>
> Try running Treesize as an administrator. Likely it’s missing the System Volume Information directory, which holds your restore points.
I was already logged in as admin. Both PCs showed the system volume folder, both about 5gb.
incidentally, on both PCs treesize shows ‘0 files missed’.
Slight correction from my OP. The second PC isn’t 29gb it’s more like 22gb. 29is the size of the ‘size’ option, not the ‘allocated space’ option.
But that’s beside the point. The point is, one of the PCs is reporting 40gb used on the pie chart, and about 16gb used in treesize.
---
### Author:  [@control-z](https://boards.straightdope.com/u/control-z)
#### Post date: [August 31, 2009, 8:00pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/5 "2009-08-31T20:00:04Z")
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.
---
### Author:  [@TBG](https://boards.straightdope.com/u/TBG)
#### Post date: [August 31, 2009, 9:47pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/6 "2009-08-31T21:47:37Z")
I don’t know what treesize is, but in my experience, the right click on a drive and choose properties method is highly accurate.
---
### Author:  [@Stathol](https://boards.straightdope.com/u/Stathol)
#### Post date: [August 31, 2009, 10:29pm UTC](https://boards.straightdope.com/t/is-windows-xp-drive-properites-accurate/508250/7 "2009-08-31T22:29:35Z")
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:
> [@](#):
>
> The allocated space that Windows shows in the properties dialog of the drive larger than the allocated space reported by TreeSize Free. The Windows Explorer shows the space that is physically allocated on the drive while TreeSize Free shows the space that is occupied by all files under a certain path. Please make sure that you have the view option “Allocated Space” activated when you are interested in the physically allocated space. Another reaon for this difference can be that not all parts of the drive could be scanned due to access restrictions. Therefore It is highly recommended to run TreeSize Free as administrator. Turn on “View \> Options \> Show Errors Messages” to get notified if a folder cannot be scanned. Beyond the space that is needed for storing the files itself, additional space is used for storing management data like the File Allocation Table of the file system or the boot sector. It is not possible to free this space with TreeSize Free or any other tool. This is usually 0.5 - 2.5% of the occupied space. Another possibility is that you are using a Software RAID - like Windows offers it - which spreads the data with redundancy over several disks. These disks will appear as one logical volume and the failure of a single disk will not cause any data loss. But for storing the redundant information additional space is needed. On Thinkpad laptops the Rescue&Recovery feature may use a lot of disk space in the folder “RRBackup” which is not accessible to other applications.
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](http://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29) (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](http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx). 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](http://technet.microsoft.com/en-us/sysinternals/bb897445.aspx), 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](http://windirstat.info/) 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.