We seem to have been struggling with the Finder’s figures for folder and volume sizes for longer than should ever have been reasonable. After a long period of apparent reliability here, last week the Finder caught me too. Given reports of similar problems on Daring Fireball and Michael Tsai’s blog, perhaps I should have realised it was only a matter of time.

What I find most surprising is the fact that so many still trust figures given by the Finder, in spite of all the evidence and experience to the contrary.

83.71 GB purgeable

In my case, what should have immediately aroused suspicion, as it did with me, was the claim of over 80 GB purgeable space on a disk that normally had none at all. That’s a huge amount of space for macOS to claim on an unsuspecting SSD. Bear in mind that only six years ago, the base version of the 13-inch MacBook Pro shipped with an internal SSD of just 128 GB, and this represents one third of the capacity of recent base models, with 256 GB.

Even including snapshots in purgeable space, 80 GB is still vast, unless a snapshot has been kept for many days or weeks. Remember that a snapshot starts off the size of the file system metadata, and only grows as the contents of that volume change. To reach a size of 80 GB would require the changing of 80 GB of data or more in that volume. In this case, that represents 10% of the whole volume being changed over the course of a day or so. Although not impossible by any means, that’s not something that quietly slips past the user, copy-on-write or not.

Second opinion

Although in some cases, we don’t have the option of obtaining a second opinion, as far as disk space is concerned we have what Apple offers as its gold standard in Disk Utility, together with several third-party options, including my own Mints, for which I know the precise source in the API. While the Finder was claiming the space “available” was over 227 GB, Disk Utility reported 144.12 GB for the same metric, and according to the appropriate API call used by Mints there was 144.12 GB “available for important usage”.

Far too often, when struggling with figures for the file system, we rely on the Finder alone when there are alternatives available.

What is purgeable?

We have also become used to a lack of documentation, to the point where many of us define concepts and measurements without reference to the documentation that Apple does provide. In researching this subject, there’s a stark contrast between the many opinions expressed as to what is included in purgeable space, and Apple’s clear definition. Just to remind you of what is written in the Help book for Disk Utility: “purgeable space” is “space that macOS can free up when needed by removing files from your computer (you can’t manually remove the files that are designated purgeable, but macOS removes them as space is required)”.

This isn’t snatched from nowhere either. We moan about the inadequacy of APFS documentation, and although it doesn’t explain purgeable space in any useful way, the current APFS Reference describes inode flags concerned with purgeability. These include INODE_IS_PURGEABLE, which marks that “this inode will be deleted at the next purge”, and comments that “a purge is requested from user space by part of the operating system, and the process of deleting purgeable files is the responsibility of the operating system.” That appears consistent with Apple’s user documentation.

Unfortunately, those inode flags don’t appear accessible through any public API, making it impossible for third-party software to inspect those flags, to verify which files are actually purgeable.

What does the Finder’s reporting of purgeable space tell us about how it treats the space used by snapshots?

As I write this, that same Data volume has a total of 3.53 GB of space taken by two snapshots (fairly typical for that volume), confirmed in both Disk Utility and Carbon Copy Cloner. Yet the Finder and Disk Utility now report that it has purgeable space of 0 bytes, as they almost invariably do. In that case, as on my other Macs running 13.3.1, space occupied by snapshots clearly isn’t being counted as purgeable. Yet in other circumstances, the Finder does appear to count snapshots as being purgeable space.

The only conclusion consistent with those observations is that sometimes the Finder counts space occupied by snapshots as purgeable, and other times it doesn’t. In other words, it doesn’t follow any obvious rule when accounting for snapshots: it is inconsistent. Tomorrow, thanks to ideas and work by kapitainsky (in comments to my articles) I will demonstrate how misleading macOS can become, and how some snapshots at least are counted as purgeable, despite Apple’s insistence that the user can’t remove them manually.

The Finder’s figures

Whatever purgeable space is, it’s increasingly clear that providing the user with ‘available’ and ‘purgeable’ space is a serious mistake. If advanced users and the Finder are unable to define and account for purgeable space consistently, giving the user that figure can only confuse. As ‘available’ space is derived from that, and founded on the assumption that macOS is going to purge as much as the Finder promises, that too is flawed.

Users are sometimes driven to extraordinary lengths in their efforts to force macOS to realise the promise made by purgeable space. As the user has little or no control over whether macOS will purge that space, it often proves an empty promise. Purgeable space is like cryptocurrency and NFTs in promising a potential that might never be realised.

The Finder should report actual free space, and not refer to space macOS might free up if and when it feels like it. If free + total used space in that container doesn’t come very close to its total capacity, then the Finder will only continue to lead users astray.

But tomorrow I will demonstrate how APFS volumes don’t actually share space in a container, and how to make free space vanish on an apparently empty SSD.