Dave Nanian:

Recent versions of xOS (that is, macOS, iOS, iPadOS, etc) have Data Protection Classes from A to D that get assigned to files and folders.

[…]

The thing is, though, is that these files and folders are inaccessible unless the user is logged in, and the screen is unlocked. A few seconds after the screen locks (or you log out), the keys are purged, and they cannot be read.

[…]

That means the files any application considers to be worth protection cannot be accessed when a backup usually happens.

[…]

You may have noticed that if you had an overnight backup, when you unlock your screen, a copy starts to run. It’s typically quite brief, thanks to ⚡️Turbo Smart Update, but it might surprise you anyway. […] During your overnight copy, SuperDuper kept track of the files that it couldn’t access due to their protection class. And now that it can access them, it’s making sure they get backed up.

This seems like the right thing to do. Time Machine also does it. A backup app should try to make as faithful a backup as possible. I kind of find it annoying, though. Sometimes it can’t do a Turbo Smart Update, and so the backup that should already be done may end up taking another 30 minutes or more. The best thing to do is schedule backups while you’re using your Mac to avoid SuperDuper needing to do such “follow-ups.”

I wrote some code to try to figure out which files I have that are using data protection. Interestingly, the URLFileProtection API seems to not work on macOS. I used the lower level getattrlist() instead. Nanian recommends fcntl(). I didn’t find any protected files that I actually care about, just caches and derived data from Apple’s own apps. But, in theory, Apple or a third-party app could be saving actual user data using data protection.

Previously:

• SuperDuper 4
• Launching Before UserDefaults Is Available
• Apple Addresses iOS Surveillance and Forensics Vulnerabilities

Howard Oakley:

Since High Sierra and APFS snapshots, accounting for purgeable space has been inconsistent and often misleading. I first reported this over eight years ago in Sierra 10.12.6 and High Sierra 10.13.3, and most recently three years ago in Ventura 13.3.1. This article looks at how this is handled now in Tahoe 26.6.2.

[…]

There is disappointingly little documentation on space management in macOS, and the closest Apple comes to defining purgeable space is in Disk Utility’s Help pages, where it’s stated to be “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)”.

On the face of it, that includes cache files but not snapshots, as they can be manually removed in Disk Utility, as I’ve discussed in detail here. This is contradicted when using tmutil localsnapshot to make Time Machine snapshots, which reports that “local snapshots are considered purgeable and may be removed at any time by deleted(8)”, as deleted is the purgeable space and cache management service in macOS.

APFS snapshots can also be created by third-party apps that have the appropriate restricted entitlement. Apple doesn’t explain whether those too can be purged by macOS when additional free space is required.

Howard Oakley:

Before macOS will start copying a file to a volume, it checks whether there’s sufficient free space available. I believe this is normally performed by the FileCoordinator API in Foundation, and appears in the log with the subsystem com.apple.foundation.filecoordination.

If there isn’t sufficient free space to accommodate the file to be copied, deleted in the subsystem com.apple.cache_delete checks whether enough space can be freed by purging items known to be purgeable in the destination volume. deleted has a fixed set of services that can be called on to purge items, listed in /System/Library/CacheDelete.

[…]

Space-based purging of Time Machine local snapshots is unreliable. The reason for this is that Time Machine CacheDelete fails to report purgeable space when it’s available. Even when it does work, it can take nearly half an hour for Time Machine CacheDelete to recognise the appearance of purgeable space.

Sometimes you need to do it yourself with Disk Utility.

Previously:

• SuperDuper 4
• Tahoe Free Space Problems
• Purgeable Disk Space
• Purgeable Mac Apps
• Time Machine Evolution and APFS
• What You See in the Finder Should Always Be Correct
• Quantum Computing and APFS: Free and Used Space
• How OmniDiskSweeper Reports Free Space
• Local Time Machine Uses APFS Snapshots

Update (2026-09-03): Howard Oakley:

• When purgeable space is required, deleted (subsystem com.apple.cache_delete) first discovers purgeable space for each caching service, to determine whether it’s sufficient.
• If it is, and the decision is taken to purge caches, caching services are called on to free up space by purging their caches as required.
• Purging may then take place in phases until sufficient space has been freed.
• Purging is frequent during installation of macOS updates, even when there’s ample free space available.

Update (2026-09-08): Howard Oakley:

In the event that you’re caught out by circumstances, such as the combination of recent large snapshots and exceptionally large caches, macOS does try to manage as well as possible even when there’s just a few GB free. But once free space falls to around 1 GB you should see a warning notification.

[…]

From then on, most file operations, even creating a new folder, will fail. That applies to all apps, regardless of whether they handle those failures gracefully and warn you of the error. Actions like taking a screenshot start normally, but after their image has floated across the display, they just vanish and can’t be saved.

[…]

The worst combination of problems occurs when a Mac runs out of free disk space and physical memory at the same time. macOS memory management then wants to allocate space in the VM volume as its backing store for virtual memory, but in the absence of free space to do so, that fails and should propagate as a memory allocation error.

Update (2026-09-09): See also: Accidental Tech Podcast.