The Mac is full of illusions, and always has been. The success of those illusions is what makes the Mac. We all know that there’s no real Desktop, that displaying directories as folders is mere visual artifice, and iCloud Drive doesn’t contain files as such. But to be successful, even magic like macOS has to comply with some basic rules.

The first is to remain truthful. Although the line between illusion and inaccuracy may appear indistinct, there are some things you can get away with, and others you definitely can’t. Hiding files and folders you don’t want the user to see, like the Library folder in a user’s Home folder, is fair game so long as you provide advanced users a means of access. You also have to remain consistent: if one part of the GUI tells a user that a volume has 140 GB of available space, but somewhere else they’re told that there’s over 220 GB, that confuses and destroys user confidence.

In the last couple of weeks, I have shown here two examples (here and here) where what is displayed by the Finder is manifestly untrue, and very different from what has been shown elsewhere, notably in Disk Utility. Various reasons have been suggested as to why those may have occurred, but a common contention has been that the Finder needs to simplify the figures it gives for disk space. Here I consider whether that’s possible, using a simple example and some basic arithmetic.

Classes of space

We know from looking inside macOS space management that storage space is divided up into different classes:

• capacity, the size of the container (partition) containing the volumes, which for most external disks normally comes close to the capacity of the disk as they have but a single container;
• used, the amount of space currently being used to store files and the file system, including any that are purgeable;
• free, which I’ll distinguish here as unconditional free space without any purging of its current contents;
• purgeable, the amount of space that macOS could free if wanted;
• available, the sum of free and purgeable space, representing the maximum space that could be made available for use if macOS purged fully.

There are two complications. Most importantly, some purgeable space is available to any volume in a given container, but some, most significantly snapshots, is only available to the individual volume being purged. This makes the expression of space difficult, as Apple’s model for the ordinary user doesn’t normally deal with containers, only volumes. That’s standard in the Finder, and in the default view shown in Disk Utility.

Worked example

For this example, I’ll take a disk containing a single 500 GB container C, within which are two volumes, A and B. Each volume has 100 GB of non-purgeable files. Volume A then has 50 GB of snapshots and other per-volume purgeable files, and B has 5 GB. There are also 10 GB of files that can be purged from either volume, being purgeable at a container level; those are divided evenly between A and B, i.e. 5 GB each.

Total space used on the disk is 200 GB of non-purgeable files, plus 55 GB of per-volume purgeable files, plus 10 GB of per-container purgeable files = 265 GB. So each of the volumes should show 235 GB of unconditional free space without any purging.

Volume A has a total of 60 GB purgeable space, so its available space after purging is 235 + 60 = 295 GB. If you were to copy 280 GB of files to it, the unconditional free space of 235 GB would need to be augmented by 45 GB of purgeable space, accomplished by purging 10 GB plus at least 35 GB of its snapshots and other per-volume purgeable space.

Volume B has a total of 15 GB purgeable, so its available space after purging is 235 + 15 = 250 GB. If you were to try to copy 280 GB of files to it, purging would be unable to create sufficient space, with a shortfall of 30 GB, which is locked away in the snapshots of volume A.

Thus:

• A declares 235 GB of unconditional free space, and 295 GB of available space after purging 60 GB of purgeable space,
• B declares 235 GB of unconditional free space, and 250 GB of available space after purging 15 GB of purgeable space.

Consequences

For the whole container C, there is 235 GB of unconditional free space, and a maximum of 65 GB of purgeable space, giving an available space of 300 GB. If that figure were to be given for each of the volumes, it would be 5 GB too large for A, and 50 GB too large for B, misleading the user into thinking they can copy 280 GB into volume B, which they can’t. If the Finder, Disk Utility or Storage give any different figures, then they too will mislead the user, and destroy any confidence in those figures.

So long as some purgeable space can only be freed when purging an individual volume, purgeable and available space can’t be the same across all volumes in the same container, if they have different per-volume purgeable space. The only way to address this is to change space management, to make all purgeable space available to each volume.

The most significant contributions to per-volume purgeable space are snapshots, which are by definition volume-specific. Given the potential importance of snapshots on some volumes, I was surprised when I triggered a purge of a volume containing a 94 GB snapshot that the user isn’t warned that’s about to happen: macOS went straight ahead and deleted that snapshot. While this could be acceptable behaviour on the destination volume, if macOS were to delete snapshots on other volumes when purging, users might be surprised at not being consulted first.

I hope that you now agree with my previous conclusion, that macOS space management needs to be rethought, redesigned, implemented without inconsistencies or bugs, and thoroughly documented for users, support staff and developers. It really isn’t as simple as it might look, and whatever Apple does, the numbers must add up and remain consistent.