what happens when you delete a file (and why recovery works)

you delete a file, the disk space is gone forever. that's what everyone assumes, and it's wrong in a way that matters. file recovery tools aren't magic, and neither are the forensic tools that recover "deleted" evidence. the reason it all works is that on linux, deleting a file barely touches the file at all.

a file is actually two things

this is the part that makes everything click. on a filesystem like ext4, a file is split in two:

the inode: a little metadata record. this holds the owner, permissions, timestamps, and most importantly, a list of pointers to the actual disk blocks where the data lives
the data blocks: the actual contents of the file, sitting somewhere on the disk, pointed to by the inode

the file name you see in a directory listing is not part of the file at all. a directory is basically just a table of "name → inode number" pairs. daoudi.li.txt is a label pointing at, say, inode 531223.

you can peek at this:

ls -i notes.txt
# 531223 notes.txt

stat notes.txt
# inode, block pointers, timestamps, the whole story

so what does "delete" do?

here's the plot twist: rm doesn't delete the file. it deletes the link to it.

it removes the "notes.txt → 531223" entry from the directory table
it decrements the inode's link count. when that hits zero and no process has the file open, the kernel marks the inode as free
the data blocks get marked as available for reuse

notice what's missing from that list: nobody wiped the data. the actual bytes of your file are still sitting on the disk, exactly where they were. the filesystem just forgot they belong to anyone.

this is why the syscall behind rm is literally called unlink. that's the honest name for what's happening. "delete" would be false advertising.

why recovery works

now the recovery story makes sense. tools like extundelete or photorec scan the disk for block sequences that look like intact files (jpeg headers, pdf structures, text patterns), with no live inode pointing at them. the data was never destroyed, just orphaned.

the catch: those blocks are marked as available, so the next file you save can be written right on top of them. that's why the number one rule of accidental deletion is stop writing to the disk immediately. every write is a chance for something to overwrite your file's orphaned blocks.

the open-file loophole

there's a fun side effect of all this. a process holding a file open keeps its own reference to the inode, even after someone unlinks the file:

# terminal 1: a process holds the file
tail -f big.log

# terminal 2: "delete" it
rm big.log

# the file's gone from the directory listing...
ls big.log
# No such file or directory

# but the process still reads it, and the space is still in use
df -h    # disk space didn't come back

the data and the disk space stay alive until the last process closes the file. sysadmins know this one intimately: it's why a deleted log file can still fill up your disk, and why the fix is restarting the process holding it, not just rm.

actually deleting something

so if you ever genuinely need a file gone (selling a laptop, "sensitive" files, whatever), rm is not it. the real options:

shred: overwrite the data blocks with random junk before unlinking

shred -u secret.txt

on SSDs even that's not reliable, because the drive's wear leveling quietly keeps copies of blocks in the background. for SSDs, the answer is full-disk encryption from day one: if everything was always encrypted, an orphaned block is orphaned ciphertext