When the Finder’s arithmetic fails with an error of 139 TB

Snapshots are one of the major features of APFS, but appear almost unsupported by utilities or tools. In my quest to learn more about them, I have abandoned the tmutil command, which only concerns itself with snapshots made as part of Time Machine backups. When looking for all snapshots, you’ll need the command
diskutil apfs listSnapshots /Volumes/volname
where /Volumes/volname specifies the mounted volume you want to check. For example, on my main working external SSD, I find entries such as
+-- BC1F4585-E567-41C9-9D22-0A0A51C5213E
| Name: com.bombich.ccc.032DC3BA-9EF5-4D6B-89AC-9FA171C7C662.2020-06-12-041500
| XID: 521972
| Purgeable: Yes

for snapshots made by Carbon Copy Cloner, and
+-- 1885D22C-4B79-4406-86DA-E23AB9E5454F
| Name: com.apple.TimeMachine.2020-07-11-184430.local
| XID: 545948
| Purgeable: Yes

for those made by Time Machine.

But there seems no way to obtain an estimate of the size currently taken by those snapshots using diskutil or another command such as du. To get further information, you need to mount the snapshot first. Prepare a mountpoint for it using
sudo mkdir /Volumes/snap
which creates the mountpoint named snap ready for that snapshot.

To mount a snapshot, use a command of the forma
sudo mount_apfs -o ro -s snapshotname pathname /Volumes/snap
where snapshotname is the name given in the list of snapshots, and /Volumes/snap is its mountpoint. The contents of that snapshot should then be shown in the Finder under a manufactured volume name of the form volname@mountpoint-[digits], such as External1@snap-520593. The trailing digits are the snapshot’s XID, for which I have found a use at last.

Behaviour of that mounted snapshot is most peculiar. Disk Utility ignores it completely, so you can’t obtain any information about the snapshot from the utility in macOS which is supposed to support APFS, disks and volumes.

snapshot1

Use Finder’s Get Info command and you could see one of the strangest results I have ever seen on a Mac. The snapshot is here given the capacity of the original volume from which it was made (here 1 TB), and the space available in that seems an accurate reflection of that on the whole volume (here 221 GB). Simple arithmetic then leads you to expect that the used space should be 1,000 – 221 = 779 GB. The Finder, though, reaches the extraordinary result of 140 TB which I think is larger than the total capacity of all the storage available here, and makes no sense at all. The Finder’s error of more than 139 TB is most probably because it’s using the wrong integer type in its calculation.

snapshot2

At the command line,
sudo du -sh /Volumes/snap
returns 721 GB, which doesn’t match the Finder’s expectation of 779 GB. According to Carbon Copy Cloner, that snapshot takes only about 31.1 MB of ‘real’ storage space, which reflects what you’d expect to recover if it were to be deleted.

I happen to have an unreleased app here which iterates through mounted volumes in /Volumes and uses URL resource keys to gain estimates of sizes. Free space, given by volumeAvailableCapacityKey is given as 221 GB, which is the same as that shown by the Finder. Volume total capacity from volumeTotalCapacityKey is given as just a few MB under 1 TB, which again tallies with the Finder. This gives a total used space (the difference between those) of 778.5 GB, which doesn’t correspond to the Finder’s grossly incorrect figure, nor that from du (721 GB). No space is apparently available for important usage (volumeAvailableCapacityForImportantUsageKey), nor for opportunistic usage (volumeAvailableCapacityForOpportunisticUsageKey).

snapshot3

Once you’ve finished accessing the snapshot, you should then unmount it using a command such as
sudo umount -f /Volumes/snap

I’m no further forward in discovering how to gain an estimate of the effective size of a snapshot, although I’ve now found discrepancies between used space calculated from volume figures in a compiled app, those returned by du, and the wildly incorrect figure offered by the Finder – all of which differ from the much more reasonable answer provided by Carbon Copy Cloner.

I welcome your suggestions.