Why Windows shows two numbers for one file.

A volume does not hand out bytes. It hands out clusters — fixed-size blocks, 4 KB by default on NTFS — and a cluster belongs to exactly one file. Nothing else can use the leftover.

So a 1 KB file takes a whole 4 KB cluster and wastes three quarters of it. A 5 KB file takes two clusters and wastes 3 KB. A 4 KB file, unusually, wastes nothing. The waste is called slack, and the important thing about it is that it is charged per file rather than per byte.

On a few large files this rounds to nothing. On a build tree, a package cache or a source checkout — hundreds of thousands of tiny files — it stops being a rounding error and becomes gigabytes.

The assumption that size on disk is the bigger number is the one that catches people, because three common things break it.

Sparse files

A program can declare a file at its full final length before writing anything into it, and ask the file system not to allocate the parts it has not written yet. The file honestly reports its declared length. The volume has handed it almost nothing. This is what download managers, virtual disks and databases do when they reserve room in advance.

NTFS compression

A compressed file reports its uncompressed length as its size, and its actual occupancy as size on disk. Text and source trees can compress hard, so the gap is often large.

Files that live in the file table

NTFS stores very small files inside their own record in the master file table instead of giving them a cluster. The content is on the disk and the file is perfectly real, but it occupies no cluster of its own — so Windows reports its size on disk as zero.

Both of these were measured by Reclaim on one real disk, and both were checked against what the volume's free space actually did afterwards.

The first is sparse preallocation: Steam creates its download targets at full size before writing a byte into them, so nearly 40 GB of that first figure was never on the disk at all.

The second is cluster slack, hundreds of thousands of small files each rounding up. Deleting it returned two gigabytes more than the sum of the files in it.

One directory over-reported by 39.3 GB and the other under-reported by 2 GB. That is the part worth taking away: you cannot correct for this by being suspicious of large numbers, because the error has no fixed direction.

Summing file sizes is the easy measurement. It is one cheap call per file, it never fails, and it produces a large impressive number. Measuring allocated size is more work, and it produces a smaller and less impressive one about as often as not.

So the number most tools show you is the sum of file sizes, presented as the space you are about to recover. On the Steam directory above, that promise would have been wrong by nearly three times.

There is a second, quieter error underneath it. Space that is shared — a file with more than one directory entry pointing at the same data — gets counted once per entry by a tool that walks directories and adds up what it sees, so the same bytes are promised to you twice.

Reclaim measures allocated size, per file, and reports that as the finding. It never sums file sizes and calls the total a saving. Where the two differ meaningfully it shows both, so you can see the figure you were about to be promised beside the one you will actually get.

Because it measures occupancy rather than content, every byte on the volume is accounted for exactly once and the totals add up to the disk rather than to a list of interesting places.