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?
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
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.
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):
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.