My computer says that I have a 74.4 GB drive. Of that 231 MB are free.
TreeSize application states all my files take up 64.3 GB.
Where is the missing 10 GB?
asked Jun 19 '14 at 19:37
I'd say that a lot of that missing 10GB is in the System Volume Information folder that your screenshot shows access denied.
The System Volume Information folder is where your System Restore snapshots are saved. Try disabling System Restore and see how much space that saves you.
You may also be losing space to the Offline Files feature, which stores information in C:\Windows\CSC -- another folder which TreeSize likely cannot see into.
answered Jun 19 '14 at 20:14
-
So I checked... System Protection was on, but it didn't take any space because there were no System Restore snapshots. I turned it off anyway. The Offline Files were on as well, but also were taking up zero space. I turned it off too. No change in disk space usage whatsoever. – AngryHacker Jun 19 '14 at 21:56
Most likely, you have hidden pagefile.sys and/or hiberfil.sys in root directory of drive C:.
Try to enable showing hidden files in Windows Explorer and check what is their current size.
The reason for this could be a discrepancy between the size of a file and the amount of space it actually consumes on disk because of block sizes. Look at the properties of any file and I believe windows shows you both. I suspect explorer is listing the consumed space where as treesize is listing the file sizes.
It seems to be a quirk of TreeSize.
You can hold the mouse over "C:\" in TreeSize, and you will see a field for "size" vs. "allocated", by the way, but this would not explain your difference (nor would other answers here regarding difference in allocated space) as TreeSize reports the allocated space (meaning that TreeSize would show a higher total than the sum of the file sizes, which is what you want).
There is a good general article about free space discrepancies in NTFS, although that primarily refers to discrepancies in what Explorer reports, and does not cover the difference between Explorer and TreeSize.
On my system (1TB drive with 4K clusters):
- TreeSize reports 218,215.4 MB used
- TreeSize reports 219,231.0 MB allocated (1GB wasted)
- Explorer (drive properties) reports 259,068.5 MB used (reports cached free space value, shows ~40GB more than TreeSize)
- Explorer (select all files => properties) reports 254,749.0 MB used (does actual calculation, leaves out hidden files, still shows ~35GB more than TreeSize)
- chkdsk reports 258,166.9 MB used for files
- chkdsk reports 354.8 MB used for indexes (TreeSize will not show this)
- chkdsk reports 1055.66 MB used by the system (e.g. volume info TreeSize will not show this)
- chkdsk reports 64.0 MB used by the NTFS log
- chkdsk's total (259,641.4 MB) roughly matches Explorer's total (259,068.5 MB), TreeSize is the odd man out.
- TuneUp Disk Space Explorer reports 252,794.88 MB (excludes system and hidden files, very close to Explorer)
Some discrepancies can be expected above due to the various techniques used to tally space, the list of files included, and especially hard drive activity that happened while I was performing the above (temporary file activity, search indexing, browser caching, etc.). So slight mismatches can be considered "close enough", but 35GB is not a slight mismatch.
As you can see, TreeSize is the odd one out. Explorer (both reported and tallied free space), chkdsk, TuneUp DSE, and df all reported consistent results. TreeSize is missing about 30-40GB of data.
That's not to say TreeSize is no good; I just wouldn't trust it to report all the data on the drive. That said, however, the data it is missing is likely data you would not want to or be able to delete anyways. TreeSize is still a perfectly good utility for locating trouble spots and data that can potentially be moved to other drives or deleted.
People here and elsewhere mentioned not having the right permissions, not having the right tools, system restore points (VSS), Alternate Data Streams, symlinks, hard links, junction points and you name it.
But I think something has never been touched: drivers. Or at least this is the only explanation I can give after having tried everything without success.
I was having this super odd problem with VirtualBox 5.2, whereas writing to an NTFS compressed destination in the host OS, from the guest via shared folders resulted in exponentially more and more missing space. But just reboot (or once just right while I was shutting down the VM) and everything fixes by itself.
So after mindstorming, I noticed that its kernel drivers (VBoxDrv or at worst VBoxNetAdp) seemed to get stuck every time I tried to unload them. And my assumption is that somehow they are virtually pre-allocating disk that they'll never use.
It seems as if that program is not event taking into account the sizes of the page- or swap-file. Usually, they have a size in the dimensions of your RAM, so there could be the missing 10 GB.
chkdskon the drive, and also reboot the machine -- after that the free space counts will all be consistent and you can see if the issue persists. Until you do that, you're just guessing. – Jason C Jun 19 '14 at 23:18