Data Recovery Case File · Developers & Linux · The Wrong-Path rm

Deleted where the filesystem forgets hardest: an rm against the home directory, an instant power-off, an honest map of the odds — and the uncommitted code carved home by content

His enquiry was written in the fluent self-deprecation of someone who knew exactly what had happened within about a second of doing it. The machine: a Lenovo laptop on a Ubuntu-family system. The act: "I cleverly nuked my home directory with rm -r * instead of the /tmp/ directory I was intending." The stake: Python code "yet to be committed to source control." His response, and the case's foundation: "I immediately realised what I'd done and powered off the machine" — then investigated properly, booting a live USB and running a respected open recovery tool read-only, which "showed the directories as deleted but didn't find any further subdirectories or files." Email preferred, honoured throughout. The empty result felt like the verdict. It wasn't — it was the filesystem behaving exactly as documented, and the honest decode below explains both why his tool came back empty and why his data mostly hadn't gone anywhere.

The decode: what this filesystem forgets on delete, why his tool's empty result was expected — and where the code actually was

The honest ext4 truth, stated up front because developers deserve it straight: on this filesystem family, deletion is more forgetful than Windows users are used to. Removing a file doesn't erase its contents — the data blocks stay on disk until something overwrites them — but the filesystem zeroes the file's block map on delete: the record of where each file's pieces live is discarded at the moment of removal. Which decodes his investigation perfectly: his tool found the directory skeletons (their entries linger) but "no further subdirectories or files" — because the pointers from names to blocks were, by design, already gone. The empty result wasn't the tool failing or the data missing; it was an accurate report that the map was destroyed — the standard, documented shape of this exact accident, and the reason structure-first recovery has a low ceiling here. The two roads that remain, honestly graded: the filesystem's journal sometimes retains fragments of recent metadata — worth mining, occasionally generous, never guaranteed — and beneath it lies the road his cargo was made for: content carving. The blocks themselves survive un-mapped, and source code is the friendliest carving cargo in existence — plain text, small files (usually landing in single contiguous blocks, sidestepping the fragmentation that plagues carved video), and dense with searchable signatures: language keywords, import lines, his own function names and comment style. A codebase can be fished out of raw blocks by what it says, then reassembled and de-duplicated by a reader who knows what a project looks like. And the foundation under all of it — his power-off: deleted-but-unmapped blocks survive only until the system writes over them, and a running Linux machine writes constantly — logs, caches, browser churn, the works. Killing the power within seconds froze the free-space pool almost untouched; every subsequent step read-only from live media kept it that way. His reflexes didn't improve the odds. They were the odds.

The recovery — by journal, then by content, verified like code

The drive was imaged write-blocked and both roads ran on the copy. The journal yielded its occasional generosity in part — recent metadata fragments restoring names and locations for a slice of the estate — and content carving did the heavy lifting for the rest: the free-space pool swept with signatures tuned to Python and plain text, candidate blocks recovered, assembled and de-duplicated into files, with his priority target rising exactly as the theory promised: the uncommitted source, recovered by its own words. Verification ran developer-native: files syntax-checked, the project's imports resolving against its own recovered modules, recent-edit versions distinguished from stale duplicates by content and internal dating — and delivery went by email arrangement onto fresh media, the recovered tree organised for a straight commit. The report closed with the honest ledger this filesystem's design demands: names and paths partially reconstructed, contents substantially recovered, the bounded losses itemised where system churn in those first few seconds had already claimed blocks — and one line of engineer-to-engineer respect: the power-off was the recovery's first and best operation; everything here built on it.

Outcome

The uncommitted work home and committing — and the filings for every terminal jockey one mistyped path from this page. Kill the power, not just the process: on this filesystem family the contents outlive the delete but the map doesn't, and every second of uptime spends free-space blocks — his instant power-off is the entire playbook, and it beats any recovery tool ever written. Read an empty structure-scan correctly: directories-without-files after an ext4-family delete is the design, not the verdict — the recovery road is content, and code travels it beautifully. Investigate only read-only, from live media, exactly as he did — and report findings precisely; his three-line account pre-wrote the assessment. And commit early, commit often: source control exists so that rm can only ever cost you the afternoon — the recovered project's first act, by mutual agreement, was a push. Clever nuking, he called it. Cleverer everything-after — and the code, which never actually left the disk, is back under version control where wrong paths can't reach it.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.