File deletion
A Socratic walk-through of file deletion — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why is deleting a file not the same as erasing what it contained?
Empty the trash on a ten-gigabyte video and the operation finishes instantly. Ten gigabytes, gone, in less time than it takes to blink. Compare that with writing the same file, which took minutes. If deletion really removed the contents, why would it be thousands of times faster than putting them there? Something is clearly not being done.
Reasoning it through
REASONING #Start with what a filesystem actually is. There are the data blocks — the raw contents, scattered across the disk — and there is bookkeeping: a directory entry mapping a name to a record, that record (an inode, in the Unix family) describing ownership and size and listing which blocks hold the contents, and an allocation map recording which blocks are in use.
Now ask: to make a file stop existing, what is the minimum the system must do? It must remove the name from the directory so nothing can find the file, and it must mark those blocks free so they can be handed to the next writer. Both are small edits to bookkeeping. Neither touches the ten gigabytes.
And the data? It sits exactly where it was. Not preserved deliberately — simply not visited. Overwriting ten gigabytes would cost ten gigabytes of writing, and the system gains nothing from it, so it does not. That is the entire answer to why deletion is instant, and simultaneously the entire answer to why recovery works.
Follow the consequence. Undelete tools do two different things. If the record is still intact, they relink it. If it is not, they fall back to carving — scanning the raw disk for the byte signatures that begin known file formats, and reconstructing from there, which is why carved files often come back with the right first half and garbage after it. Both work only until the allocator hands those blocks to a new file and something writes over them. Recovery is therefore a race, and the fastest way to lose a deleted file for good is to keep using the disk.
So if the ordinary delete does not erase, what does? On a spinning hard disk the answer was straightforward: write over the blocks. A single pass is enough on any modern magnetic drive — the famous thirty-five-pass Gutmann scheme addressed encoding schemes obsolete by the mid-1990s, and NIST's media-sanitisation guidance treats one overwrite as adequate.
Now the modern complication, and it is a real one. On a solid-state drive you cannot reliably overwrite in place. Flash must be erased in large blocks before rewriting, and cells wear out after a bounded number of cycles, so the drive interposes a translation layer: when you "overwrite" a logical address, the controller writes the new data to a fresh physical page and quietly remaps the address, leaving the old page holding your old contents until garbage collection gets to it. Wear levelling deliberately spreads writes around to prolong drive life. The operating system does not know, and cannot know, where anything physically lives.
What does TRIM do here? It tells the drive "these logical blocks are no longer in use", so the controller can erase them at its leisure instead of copying dead data during garbage collection. That usually results in the data becoming unreadable, but the timing is the controller's business, not yours, and drives also hold over-provisioned spare capacity that no host command addresses at all.
Where does that leave someone who genuinely needs data gone? The honest answer is: not with overwriting. Full-disk encryption, enabled before the data was ever written, means every physical page holds ciphertext. Destroy the key — a few hundred bits, held in a small dedicated area or a security chip — and every copy, every remapped page, every over-provisioned block becomes noise simultaneously. This is what the ATA and NVMe "cryptographic erase" commands do, and what a phone does when you factory-reset it in seconds.
The analogy
THE ANALOGY #Think of a library card catalogue. Deleting a file is pulling the index card and adding the shelf to a list of space available for new acquisitions. The book stays on the shelf, readable by anyone who walks the stacks, until a new arrival is put in its place. Nobody removed the book, because removing the card was the only part anyone needed done.
In a library the shelves are fixed and you could at least go and physically pulp the book, whereas on a solid-state drive the librarian is free to move books to different shelves without telling you, so you cannot be certain which shelf to visit — which is why the practical answer is to write every book in a cipher and burn the key instead.
Clarifying the model
THE MODEL #A few refinements tie the steps together.
"Deleted" is not one state but several: the name removed while a running program still holds the file open, so the blocks stay allocated; the name removed and blocks marked free, which is the ordinary, recoverable case; and blocks reallocated and partially rewritten, which is where carving gets you fragments. Only after full reuse — or a cryptographic erase — is the content genuinely unavailable.
Second, the filesystem is not the only place your data went. Journals, snapshots on copy-on-write filesystems, backups, thumbnails and cloud sync copies are all separate objects, and unlinking the original does nothing to any of them. Erasure is a property of the whole system that touched the data, not of one file.
Third, the encryption answer only works if the encryption predates the data. Turning it on afterwards encrypts what the filesystem currently considers live; it does not reach the free blocks or remapped flash pages holding yesterday's plaintext. The precaution has to be taken before you need it, which is the uncomfortable part.
A picture of it
THE PICTURE #How to readStart at Live and follow the ordinary delete arrow to Unlinked — notice it says nothing about the contents. The back-edge from Unlinked to Live is undelete, and it exists only while the blocks have not been handed out. Carvable is the state where the bookkeeping is gone but the raw bytes remain, which is what forensic carving exploits; the self-loop on it is the solid-state case, where a remapped page can sit in that state indefinitely beyond the operating system's reach. Only two arrows genuinely end the file: reuse of the blocks, which is unreliable on flash, and cryptographic erase, which reaches every copy at once.
What became clearer
WHAT CLEARED #Deletion is a bookkeeping operation — unlink the name, mark the blocks free — and it is instant precisely because it never touches the contents. That single design choice explains both why undelete and forensic carving work and why secure erasure has to be a separate, deliberate operation. On spinning disks that operation was overwriting; on solid-state drives, wear levelling and the translation layer make overwrite-in-place unreliable, so the practical answer is full-disk encryption from the start, where discarding a key of a few hundred bits erases everything at once.
Where to go next
ONWARD #- How copy-on-write filesystems and snapshots keep old versions alive long after a delete.
- What ATA Secure Erase and NVMe Format actually instruct the drive to do, and how far you can trust it.
Key terms
TERMS #| Term | What it means |
|---|---|
| Inode | the filesystem record holding a file's metadata and the list of blocks containing its contents. |
| Unlink | removing a directory entry pointing at a file, the operation an ordinary delete performs. |
| File carving | recovering data by scanning raw storage for known file-format signatures rather than using filesystem metadata. |
| Wear levelling | an SSD controller's practice of spreading writes across physical cells to extend drive life, which decouples logical from physical addresses. |
| TRIM | a command telling an SSD which logical blocks are no longer in use so its controller can erase them. |
| Cryptographic erase | rendering data unreadable by destroying the encryption key rather than the data itself. |
Every term the collection defines is gathered in the glossary.