A macOS build machine reports its disk is nearly full, but deleting tens of gigabytes of files barely moves the free-space number. How do APFS snapshots explain this, and what actually releases the space?

## Why deleting files can free nothing APFS is copy-on-write, so a block is never overwritten in place and a block is only returned to the container's free pool when *nothing* references it any more. A **snapshot** is a reference-holder: a read-only, point-in-time image of an entire volume, created almost instantly because it does not copy data — it just pins the volume's object map so every block reachable at that moment stays reachable. That is the whole explanation for the symptom. Deleting a 40 GB folder removes its entries from the live volume's tree, but if an hour-old snapshot still contains those files, the blocks remain referenced and cannot be freed. From the user's point of view the disk "refuses" to give the space back. ## Where the snapshots come from on a Mac Nobody creates these by hand, which is exactly why the symptom is confusing. **Time Machine local snapshots.** When Time Machine is configured, macOS takes a snapshot of the Data volume roughly hourly, keeps them for about 24 hours, and thins them automatically when free space runs low. They exist so you can restore recent files with the backup disk absent. **System updates.** macOS snapshots the system before installing an update, which is what makes an interrupted or bad update reversible. **Backup and imaging tools.** Third-party backup software commonly snapshots a volume to get a consistent view while copying it, and a crashed run can leave the snapshot behind indefinitely. On a CI machine, all three sources compound: churn is enormous, files are created and deleted constantly, and every hourly snapshot preserves a full generation of build output that the live volume no longer has. ## Purgeable space, and the disagreeing numbers macOS classifies snapshot-pinned blocks as **purgeable** — space the system believes it can reclaim on demand by thinning snapshots — and folds it into the "available" figure surfaced in Finder's storage view. Traditional tools that ask the filesystem for genuinely free blocks see the smaller, honest number. Hence the classic report: the Storage pane claims plenty of room while a build fails on ENOSPC, or `df` and Finder differ by tens of gigabytes. The practical reading: *free* means allocatable right now; *purgeable* means allocatable only after something is deleted first. ## Inspecting and releasing Snapshots on a mount point are listed and managed through Time Machine's tool: ```bash tmutil listlocalsnapshots /System/Volumes/Data tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4 ``` `thinlocalsnapshots` asks the system to delete snapshots until roughly the requested number of bytes has been reclaimed; the trailing urgency argument controls how aggressively it does so. `deletelocalsnapshots` removes a specific one by its timestamp. Space returns only as each snapshot goes away and its last reference on each block disappears — so removing the oldest snapshot may free little if a newer one saw the same data. A subtlety worth stating in an interview: the automatic thinning is *reactive*. It fires under space pressure, and a workload that allocates faster than the thinner reclaims can still hit ENOSPC despite gigabytes of purgeable space. ## The same mechanism is a feature Do not present snapshots purely as a hazard. The properties that pin your space are exactly what make macOS's system updates safely reversible, what lets Time Machine capture a consistent image of a live volume without quiescing it, and what lets the running system boot from a read-only snapshot of the sealed System volume. A snapshot costs nothing when taken and grows only as the live volume diverges from it — the cost is proportional to churn, which is why a CI machine feels it and a lightly used laptop does not. ## Diagnosing this in the field The reasoning chain an interviewer wants: 1. Free space did not move after deleting files, so something still references those blocks. 2. On APFS the reference-holders are snapshots and clones. 3. List the volume's snapshots and compare their ages with the deletions. 4. If the pinned space is snapshot-held, thin or delete the snapshots rather than hunting for more files to remove. 5. Prevent recurrence: bound the churn, or reconsider running Time Machine on a machine that rewrites its whole working set every hour. ## The one-line version On a copy-on-write filesystem, deleting a file is not the same as freeing its blocks. Space comes back when the last reference goes — and on macOS the last reference is usually an hourly snapshot you never asked for.