Finder's size on disk ignores APFS clones, off by 10.48 GB on macOS Tahoe (September 5, 2026)

What Get Info gets wrong

The behaviour is stated precisely in the source: "The Finder's Get Info figures allow for sparse files when giving size on disk, but don't take into account shared data in clone files." A clone on APFS is a second reference to the same blocks on disk, so two files can be 107 GB each in name and share almost all of their storage in fact.

Get Info handles half of that correctly. It understands a sparse file, where the nominal size is larger than the blocks actually written. It does not understand a clone, where two nominal sizes share one set of blocks. So when you ask the Finder how much space two clones occupy, it answers as though nothing were shared, and when you ask it how much space a modified clone occupies, it does not notice the blocks that have stopped being shared.

The result is an error that runs in both directions, which is worse than one that runs consistently high or consistently low. You cannot correct for it with a rule of thumb.

The worked example, in numbers

The test used a virtual machine and a clone of it, which is the case where clone files matter most: a virtual machine is a single very large file that people duplicate.

The last two rows are the part to keep. After the clone was modified, so that it genuinely occupied more of the disk, Get Info did not move at all. It reported the same 54.57 GB while real usage had risen to 65.05 GB, an understatement of 10.48 GB.

Which macOS versions this covers, and what is not published

The demonstration was run across macOS Tahoe, macOS Sequoia and macOS Sonoma using virtual machines, so this is not a single-release regression. It is how the Finder has been reporting size on disk on APFS.

Two things are not published, and I am not going to fill them in. The article names no macOS build number, so I cannot tell you the exact build the figures came from, only that the surrounding series of tests runs on macOS Tahoe 26.6.2. And Apple has acknowledged nothing, with no fix announced as of September 5, 2026.

The author also does not call it a bug, and neither will I. He frames it as a standing limitation of what Get Info measures. The practical effect on someone trying to free up space is the same either way: the number on screen is not the number on the disk.

What else was published about the Mac on September 5

Very little, and I would rather say so. The Mac items 9to5Mac ran on September 5, 2026 were a MacBook Ultra pricing rumour, an Apple at Work column on bug bounty caps, and Labor Day deals. No macOS bug coverage appears among them.

So there was no macOS point release, security update or acknowledged regression attached to September 5, 2026. This storage-reporting piece is the one dated, testable macOS finding for the day, which is why it is the whole of this post.

What you can do today

1. When you need to know how much space something takes, open Disk Utility rather than reading Get Info. Disk Utility's Available figure accounts for the space saved by clone files; Get Info does not.

2. Know what that trade costs you. Disk Utility reports at volume level, so you lose the ability to attribute space to a particular file, and the same testing recorded occasional anomalies in Disk Utility too. It is the better of the two numbers, not a perfect one.

3. Before you delete anything to free space, check the volume figure in Disk Utility first and again afterwards. If the Available figure does not move the way Get Info predicted, the difference is the clone sharing you could not see.

4. Treat Get Info's size on disk as unreliable on any volume that holds duplicates of large files, virtual machines above all. That is where the test found the gap, and it is where the gap is widest.

5. Do not go looking for a patch. Nothing has been acknowledged and nothing has been announced as of September 5, 2026, so the answer is to read the right number rather than to wait for a fix.