Why a Deleted File Isn't Gone: Unlink, Unallocated Space & Slack

The command is called rm for remove, and almost everyone reads that as 'erase.' It is not. On a Linux filesystem a file is really two separate things: the data (bytes sitting in disk blocks) plus an inode (a small record holding the file's size, permissions, timestamps, and the list of which blocks hold its data). A filename is neither of those — it is just a link: an entry in a directory that maps a name to an inode number. You can even have several names for the same file (hard links), all pointing at the one inode.

So when you rm notes.txt, the kernel does something narrower than 'erase': it removes the directory entry (that name-to-inode link) and decrements the inode's link count. Only when that count hits zero — no names left pointing at the inode — does the filesystem mark the inode and its data blocks as free. And 'free' means available for reuse; it does not mean overwritten. The bytes are still lying in those blocks, untouched, exactly as they were. That gap between 'freed' and 'erased' is the whole subject of this lesson, and it is why an accidental rm is sometimes recoverable and a deliberate one is sometimes a false sense of security.

When the last link is gone and the blocks are marked free, they become unallocated space — space the filesystem considers available, but which still physically contains the old file's bytes. Nothing goes back and zeroes them; that would be enormously wasteful, so no filesystem does it on delete. The old content simply sits there until the filesystem happens to hand one of those blocks to a new file and writes over it.

That 'until' is the important part, because the window can be minutes or months. On a nearly empty disk, deleted data can survive for a very long time — the allocator has plenty of fresh blocks to use and rarely revisits the freed ones. On a nearly full, busy disk it may be overwritten within seconds. This is why forensic advice is always to stop writing to a disk the moment you realize you need to recover something: every new file, every log line, every browser cache write is a chance to land on the blocks you want back. Unallocated space is not empty — it is a graveyard of everything recently deleted, slowly being paved over.

Disks hand out storage in fixed-size blocks (commonly 4096 bytes on ext4). A file almost never divides evenly into whole blocks, so its last block is only partly used — and the leftover tail of that block has to contain something. That unused remainder is file slack, and it is a second place old data hides.

Picture a 5000-byte file on a 4096-byte-block filesystem: it needs two blocks. The first is full; the second holds only 904 bytes of the file, leaving 3192 bytes of slack. What is in that slack? Whatever occupied that block before — the tail of some earlier, now-deleted file. The new file's metadata says it is 5000 bytes, so normal tools only ever show you those 5000 bytes; the slack is invisible to cat and ls but plainly readable to a tool that reads the raw block. Slack is why 'I overwrote that area with a new file' is not a reliable wipe: a smaller new file leaves the back of the block untouched, still carrying the old bytes.

Put the two together — unallocated blocks that still hold old files, plus slack — and recovery stops being magic. There are two broad approaches. Metadata-based recovery uses filesystem structures that survive a delete: on ext4 the journal or a freed inode may still list which blocks a file used, so a tool like The Sleuth Kit can reassemble it precisely. File carving ignores filesystem metadata entirely and reads the raw bytes of unallocated space looking for file signatures — the fixed 'magic' bytes that mark the start (and sometimes end) of known formats: %PDF for a PDF, \xFF\xD8\xFF for a JPEG, PK for a ZIP. When a carver finds a signature, it copies from there until the file's end marker or a size limit, and hands you the file back with no help from the filesystem at all. Tools like foremost, scalpel, and photorec are carvers.

Carving is powerful precisely because it needs no intact metadata — it works on a wiped directory, a reformatted partition, or a raw disk image. Its limits follow directly from the mechanics above: it can only recover what has not been overwritten, it struggles with fragmented files (whose blocks are scattered, not contiguous), and it recovers the bytes without the original filename or timestamps (those lived in the inode). This is the exact skill practiced in the Recover a Deleted File room, where the notes are gone from the directory listing but the blocks are still in the image.

A carver hands back bytes, not meaning: the recovered file has no name, no timestamps and no path, just a number for where it was found. So the first two moves on anything carved are the same as on any unknown file. `file` confirms the signature really produced the type you wanted (a carver that over-ran a fragment gives you a broken or truncated file). `strings` then prints every run of printable characters, which on a photo or a document surfaces the text people hide in them: a JPEG comment, EXIF fields, a name or an address.

If rm only unlinks, real deletion means overwriting the bytes so there is nothing left to recover. For a single file on a traditional disk, shred does this: it overwrites the file's blocks with several passes of data (and with -z a final pass of zeros), optionally removing the name afterward with -u. Overwrite the blocks and the old contents are genuinely gone.

But shred rests on one assumption — that writing to the file overwrites the same physical blocks — and modern storage breaks that assumption in three important ways, so be honest about them:

• Journaling and copy-on-write filesystems (ext4's journal, and especially btrfs/ZFS, which never overwrite in place) may keep copies of the data elsewhere that shred never touches.
• SSDs and flash use wear-leveling: the drive silently redirects writes to different physical cells, so 'overwriting' a file may leave the original cells intact and unreachable by any normal command.
• Copies you forgot — backups, snapshots, slack in other files, RAM, swap.

Because of this, the assured way to make data unrecoverable at scale is not to chase every block but to encrypt the whole disk from the start and destroy the key (a few bytes to erase makes terabytes unreadable — 'crypto-erase'), or to wipe/destroy the entire device. shred a sensitive file, yes — but know that on an SSD or a CoW filesystem, full-disk encryption plus key destruction is the honest answer.