hoakley Macs, Technology

Why can purging snapshots fail?

Earlier this week I reported that purging Time Machine snapshots to reclaim free space was unreliable in macOS Tahoe 26.6.2. Since then I have run further tests and browsed thousands of log entries, and this article attempts to explain what I think is going wrong, and how you can work around it.

Copy files to a volume

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.

Among those is Time Machine, listed as com.apple.TMCacheDelete. In the first instance deleted checks each of the services in its list to see which if any are currently known to have purgeable items, and totals the amount of purgeable space available. If that can satisfy the free space requirement to enable the file to be copied to that volume, deleted will then call the necessary purging, check free space on completion, and should allow copying to proceed.

Test

To test this out, I created two containers of about 100 GB on an external SSD, each of which had two APFS volumes. I almost filled one of those volumes with large IPSW files, in each of the two containers. I added those volumes to the list of Time Machine backups by removing them from the exclusion list, and allowed the next scheduled backup to proceed with the backup storage disk unmounted. In the absence of that disk, Time Machine made a local snapshot to all four volumes, as expected. Just to be certain, I made another set of local snapshots using tmutil five minutes later.

I then deleted the large IPSW files from the volume in each of the two containers, and watched for the appearance of purgeable space using Disk Utility and other tools.

The following events occurred, with clock times as mm:ss elapsed since the completion of file copying:

  • 00:00 file copying complete
  • 01:xx Time Machine local snapshots
  • 06:xx tmutil local snapshots
  • 09:xx files deleted
  • 10:34 both volumes in one container reported as having 100 GB available for “important” usage (URLResourceValue volumeAvailableCapacityForImportantUsage), but still only 3.9 GB for “opportunistic” usage, with 5.19 GB free space; volumes in the other container didn’t report any change from before file deletion
  • 18:09 the same pair of volumes reported 100 GB available for important usage, and 98.78 GB for opportunistic usage; other volumes reported no changes since file deletion
  • 33:xx an attempt to copy a large file to the first volume in the first container was refused because of insufficient free space. This is detailed below.
  • 38:32 Disk Utility reported 94.88 GB purgeable on the first volume in the first container
  • 40:00-40:10 successful purge and copy of large file to the first volume in the first container. This is detailed below.
  • 45:xx No changes, and no purgeable space, reported yet in Disk Utility for either volume in the second container.

Of the two volumes that had Time Machine snapshots created which were then turned into purgeable space, only one made that available, after a period of 29 minutes had elapsed since file deletion. The other still hadn’t disclosed any purgeable space after 36 minutes had elapsed.

Purge failure

The filecoordination claim to write the copied file reads:
35.562996 com.apple.foundation.filecoordination Write options: 0 -- URL: [private] -- purposeID: com.apple.desktopservices.copyengine -- claimID: 9E99EF3B-E6EE-4B35-B52E-2AB3912C32C0

deleted failed to discover any purgeable space available, with Time Machine CacheDelete returning 0 bytes:
35.636259 com.apple.cache_delete com.apple.TMCacheDelete : 0
35.636767 com.apple.cache_delete Query Result 0 bytes on: "/Volumes/TestVolume1".
35.636779 com.apple.cache_delete CacheDeleteCopyPurgeableSpaceWithInfo result for /Volumes/TestVolume1 : {
"CACHE_DELETE_AMOUNT" = 0;
"CACHE_DELETE_CACHED_RESULT" = 1;
"CACHE_DELETE_FREESPACE" = 5186506752;
"CACHE_DELETE_NONPURGEABLE_AMOUNT" = 0;
"CACHE_DELETE_VOLUME" = "/Volumes/TestVolume1";}
and the dialog was quickly displayed to inform the user of the failure to perform the file copy
35.650780 com.apple.AppKit (app) begin modal window ffffffff

Thus, the reason for the failure was Time Machine CacheDelete returning 0 bytes instead of the 94.9 GB that should have been purgeable. That’s 24 minutes after file deletion.

Successful snapshot purging

This time, deleted was quick to discover the huge purgeable space available from Time Machine CacheDelete
00.654500 com.apple.cache_delete com.apple.TMCacheDelete : 94876508160
00.654791 com.apple.cache_delete CacheDeleteCopyPurgeableSpaceWithInfo result for /Volumes/TestVolume1 : {
"CACHE_DELETE_AMOUNT" = 94876561408;
"CACHE_DELETE_CACHED_RESULT" = 1;
"CACHE_DELETE_FREESPACE" = 5186482176;
"CACHE_DELETE_NONPURGEABLE_AMOUNT" = 0;
"CACHE_DELETE_VOLUME" = "/Volumes/TestVolume1";}

APFS then removed the two snapshots from that volume, and completed cleanup
02.937566 apfs apfs_snap_vnop_remove:1106: disk7s1 proc backupd: deleting snapshot name (com.apple.TimeMachine.2026-08-26-070329.local) w/xid 1544
02.939938 apfs apfs_snap_vnop_remove:1106: disk7s1 proc backupd: deleting snapshot name (com.apple.TimeMachine.2026-08-26-070849.local) w/xid 1549
09.593646 apfs omap_cleanup:1790: disk7s1 completed cleaning snapshot 1549, om_snap_count 0 om_most_recent_snap 1549
taking 6.66 seconds to complete.

Time Machine reported
09.597704 com.apple.TimeMachine Space-based purging deleted Time Machine local snapshot 'com.apple.TimeMachine.2026-08-26-070849.local' on disk '/Volumes/TestVolume1 in 6.7 seconds' - current free space: 100.06 GB (100,063,100,928 bytes), target free space: 12.89 GB (12,893,556,736 bytes), initial free space: 5.19 GB (5,186,482,176 bytes)
09.600702 com.apple.TimeMachine Completed space-based purging of snapshots on disk '/Volumes/TestVolume1' in 6.7 seconds - current free space: 100.06 GB (100,063,100,928 bytes), target free space: 12.89 GB (12,893,556,736 bytes), initial free space: 5.19 GB (5,186,482,176 bytes), urgency: 3, remaining snapshots: ()
that was confirmed by deleted
09.612187 com.apple.cache_delete [Purge Result (oneShot)] com.apple.TMCacheDelete purged (94876618752 / 7707074560) bytes on volume: /Volumes/TestVolume1 in 6.689190 seconds
and finally the copy proceeded.

Conclusions

  • 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.
  • Snapshot removal is inevitably one of the slowest APFS operations, and can take several seconds.
  • If you need to free up space in a container, don’t rely on the automatic purging of snapshots. Delete them yourself in Disk Utility.
  • There are puzzling discrepancies between free space reported as available for “important” usage (URLResourceValue volumeAvailableCapacityForImportantUsage) and purgeable space.
  • If you run Time Machine backups, it’s worth checking occasionally to ensure that none of its local snapshots have become orphaned, and left longer than 24 hours before removal.