What happens to a file when you delete it on APFS

Deleting a file on APFS removes its name from the directory and releases its blocks. Nothing overwrites the data itself. Whether anyone can get it back turns on three things, snapshots, TRIM and encryption. On a modern Mac with internal storage, the honest answer is almost always no.

Two kinds of people ask about file deletion on a Mac. One has lost something and wants it back. The other is selling a Mac and wants to be certain nobody else can read it. The mechanics underneath are identical. The conclusions run in opposite directions.

Moving to Trash is not deleting

Drag a file to the Trash and nothing has been deleted. The file has been moved.

On the volume holding your home folder it lands in ~/.Trash. On any other mounted volume it lands in a hidden .Trashes folder at the top of that volume, inside a folder named for your user ID, which is 501 on a Mac with one account.

Because that is a move inside a single volume, it is a rename rather than a copy. Sending a 40GB video to the Trash therefore takes no time at all. Nothing was written anywhere. One directory entry now points somewhere else.

The file remains whole, with every byte where it was. Anything that could open it an hour ago can open it now.

What Empty Trash actually does

Emptying the Trash is the moment deletion happens. It is a smaller event than the word suggests.

The operation carries a name inherited from Unix, which macOS is built on. Unlink. The file system drops the directory entry that gave the file its name and its place in a folder, then decrements the link count on the inode, the record holding the file's metadata and the map of where its content sits. Once nothing points at that inode, the blocks holding the content return to the pool the volume can write into.

That is the whole operation. Three pieces of bookkeeping, every one of them metadata.

Three other routes arrive at the same place without the Trash. Option-Command-Delete in Finder removes a file straight away. The rm command in Terminal is the unlink called by its own name. And if Remove items from the Trash after 30 days is switched on, macOS performs it for you on a timer. None of the three does anything extra. They skip the holding step. That is the only difference.

Notice what is absent. Nothing goes to the blocks themselves. Not a zero, not a random byte, nothing at all. The content sits exactly where it sat a second earlier. All that ended is the file system's willingness to admit it was there.

Why recovery software works at all

This is the gap undelete tools live in.

Data recovery software ignores the catalogue, because the catalogue no longer mentions your file. Instead they read the volume block by block, hunting for the signatures that mark the start of a known format, a JPEG header, a PDF header, a zip header, then rebuild a file from whatever follows.

The approach works, subject to two conditions that decide everything. The blocks have to still hold the original bytes, a property with a name of its own, data remanence. And those bytes have to be readable once you have them.

Everything below is those two conditions.

The snapshot exception, where recovery is trivial

One case makes all of the above irrelevant, because the file was never really deleted.

A snapshot freezes the block map of a volume at one instant. Whatever was allocated then cannot be handed back for as long as that snapshot lives.

So a file you remove afterwards disappears from the live volume and survives untouched inside the snapshot. Whole, named and openable.

A snapshot from before the deletion changes the job. You are not recovering anything. You are copying a file that still exists.

Time Machine takes these on the startup disk itself, roughly once an hour, then keeps them about a day. macOS saves another before installing any system update. Both depend on Back Up Automatically being switched on in Time Machine settings, so a Mac that never had Time Machine configured carries no such safety net. That is your window. The mechanism underneath belongs to how the Mac file system works. What snapshots do to your free space is a different question, answered in why deleting files does not free space on a Mac.

TRIM, the thing that changes the answer

On a spinning disk, released blocks sit untouched until something writes over them. Recovery can work weeks later.

Flash storage behaves differently. TRIM is the reason.

When a file system releases blocks, it tells the drive those addresses no longer hold anything wanted. The drive notes it. Later, while idle, garbage collection erases them at the flash level, because flash has to be erased in whole blocks before any part of one can be written again.

After that the drive returns zeroes when you read those addresses. Not stale data that looks like noise. Zeroes, manufactured by the controller, with nothing underneath to find.

This is where most answers to this question go wrong. They tell you the data survives until something overwrites it. That was true of hard disks and it is the wrong model for the drive in a current Mac. Nothing overwrites those blocks. The controller erases them on a schedule of its own. No write from you is involved.

Recovery on a modern internal Mac drive is therefore a race rather than a procedure. The gap between the delete and the erase is the entire opportunity. You do not control how long it lasts.

One place keeps the window open. Some USB enclosures never pass TRIM through to the drive inside. The operating system sends the command. The bridge chip drops it. The drive never hears about it. An external SSD in a cheap enclosure can behave like a hard disk for recovery purposes.

Encryption already did most of the work

Suppose the blocks survive. You still have to read them.

APFS gives every volume a volume encryption key when it creates one. That is the default rather than a setting you switch on. On a Mac with Apple silicon or the Apple T2 Security Chip, the Mac encrypts internal storage whether or not anyone ever enabled FileVault. With FileVault off, the hardware ID inside the Secure Enclave protects that key instead of your password.

Blocks pulled off such a drive by force are ciphertext. Obtaining them stopped being the hard part.

Apple names one exception and it deserves a second reading. Data added and then deleted before FileVault was turned on is not encrypted. Forensic recovery tools can read it.

What secure erase means on a Mac now

The multi pass wipe has gone. It never suited this hardware.

Apple states the position plainly. With a solid state drive, secure erase options are not available in Disk Utility. Where the button does still appear, the standards behind it say what it was for. Three passes meets a US Department of Energy standard for magnetic media. Seven passes meets DoD 5220-22-M. Both target platters.

Overwriting flash would not achieve the same thing anyway. Wear levelling sends a write aimed at one address somewhere else entirely. The original cells stay put until the controller reaches them on its own schedule.

Cryptographic erase replaced it. Destroy the key and the ciphertext becomes noise. That is what Erase All Content and Settings does, available in macOS Monterey 12 or later on a Mac with Apple silicon or the T2 chip. It throws away the key for the data volume rather than touching a single block of data.

For an external drive the equivalent is to turn encryption on before you put anything on it, then erase it normally when the time comes. On a hard disk it is different. Overwriting is still the mechanism that works there. The same goes for an external SSD whose enclosure blocks TRIM. A data erasure tool is built for that case.

The two answers, side by side

Same mechanics, read from both ends.

The uncomfortable part is that both audiences want certainty and neither gets it from the file system alone. Certainty comes from the layer above. A backup taken before the mistake. A destroyed key after the decision.