Short answer: if a program still has your file open, copy it back from /proc/PID/fd — that always works. If not, debugfs recovered my deleted files byte-perfect on ext4, and PhotoRec carved them back by content even without filenames. I deleted files on Linux on purpose, then tried to get them back three ways on 2026-10-25. Two methods restored every deleted file with checksums matching the originals exactly. The third — the tool most guides recommend first — found nothing in my test, and the reason is worth knowing before you need it.

Stop: Do This First, Before Anything Else

Deleting a file on Linux does not erase its data. It removes the directory entry and marks the space as free. The data sits there until something else overwrites it — which is why the most important recovery step is to stop writing to that drive immediately. Do not download a recovery tool onto the same partition, and if the file was on your system drive, remount it read-only if you can:

sudo mount -o remount,ro /dev/sdXN

If the file was on a separate drive or USB stick, unplug it until you are ready. Every write after deletion gambles with the exact blocks your file occupied. Also check the obvious first: if you deleted the file in a file manager rather than with rm, it is probably in the Trash. Everything below is for files deleted with rm or otherwise truly gone.

How I Tested

I built a scratch 100 MiB ext4 filesystem image with three known files: a 158-byte text note, a 50-byte to-do list, and a tiny 75-byte valid PNG image. I then deleted the note and the PNG, leaving the to-do list untouched as a control. I also deleted a text file that a running program still had open, to test the open-file trick separately. Every recovered file was checked against the original with MD5 checksums — a matching checksum is the only recovery result that counts.

One honest limitation: this VM has no loop device and no working FUSE device, so the scratch image could never be mounted normally. Files were written to and deleted from it with debugfs. That matters for one tool below.

Method 1: The File Is Still Open — Copy It From /proc

Linux only truly frees a file when nothing holds it open. If you delete a document still open in an editor, a log a program is still writing to, or a video still playing, the data is alive in that program's file descriptor even though the filename is gone. Find it with lsof | grep deleted, then copy from its /proc entry:

lsof | grep deleted
cp /proc/PID/fd/FD_NUMBER recovered-file.txt

In my test, a Python process held a text file open while I deleted it. The filename vanished, but fd 3 still pointed at it, marked (deleted). Copying /proc/PID/fd/3 back produced a file with MD5 d2fd0457ab4919815093393a19a1ddb4 — identical to the original. Recovery rate: 1 out of 1, byte-perfect, in seconds. If this applies to your file, do this now — it is the only method that is guaranteed, because nothing has been freed yet.

Method 2: debugfs — Byte-Perfect Recovery on ext4

debugfs ships with e2fsprogs, so it is already installed on most Linux systems. On my scratch image:

debugfs -R "lsdel" image.img

This found exactly the two deleted inodes — 12 (the note) and 14 (the PNG). Dumping them back out:

debugfs -R "dump <12> recovered-note.txt" image.img
debugfs -R "dump <14> recovered-photo.png" image.img

Both matched their originals exactly: the note's MD5 was 3a1d7965d818cf597989584dbf443f54 before and after, and the PNG's was d51273152a27aa1c9877dc592eaa89a7 before and after. Recovery rate: 2 out of 2, byte-perfect. The catch: debugfs only works on ext2/ext3/ext4, only helps while the deleted inode's blocks have not been reused, and must run on an unmounted filesystem or disk image — never on a mounted partition you care about.

Method 3: PhotoRec — Carving Files by Content

PhotoRec takes the opposite approach: it ignores the filesystem entirely and scans raw blocks for known file signatures, like a PNG header. That makes it the right tool when the filesystem itself is damaged, when the partition was reformatted, or when the files were on FAT, NTFS, or exFAT (USB sticks, SD cards, camera memory) where debugfs cannot help. It is free, open source, and read-only — it never writes to the drive it scans.

Running PhotoRec 7.1 over my scratch image recovered both deleted files, again byte-perfect: the PNG came back with MD5 d51273152a27aa1c9877dc592eaa89a7 and the note with 3a1d7965d818cf597989584dbf443f54, matching the originals. Recovery rate: 2 out of 2 on content. The price is that PhotoRec does not know filenames — my files came back as f0021184.png and f0021168.txt, so on a real drive you will be sorting through generically named files. On a drive with thousands of files, that sorting job is the real cost of this method.

The Tool That Found Nothing — and Why That Is My Test's Fault

The tool most guides tell you to run first on ext4 is extundelete, and its own documentation explains why: it recovers files by reading the filesystem's journal for old copies of deleted inodes. On my scratch image, extundelete 0.2.4 reported "0 recoverable inodes found. No files were undeleted." That is not evidence that extundelete fails in real use — it is evidence about my test setup. Because the scratch image was never mounted and the deletions were made with debugfs, no journal entries for those deletions ever existed for extundelete to read.

On a real system, where files are deleted normally on a mounted ext3/ext4 partition, the journal is exactly what extundelete reads, and it is still the right first tool there because it can restore original filenames, unlike PhotoRec. The procedure: unmount the partition (or work on a dd image copy of it), then run:

sudo extundelete /dev/sdXN --restore-all

Recovered files land in RECOVERED_FILES/ in the current directory — which must be on a different drive than the one you are recovering from. The lesson: a recovery tool is only as good as the metadata your setup actually recorded.

Which Method Should You Use?

  • A program still has the file open: copy it from /proc/PID/fd immediately. Guaranteed and instant.
  • Deleted from ext4, acting fast: try extundelete on an unmounted partition or image copy first (it keeps filenames), then debugfs lsdel + dump if it comes up empty.
  • Filesystem damaged, reformatted, or not ext (USB stick, SD card, NTFS): PhotoRec. It recovers by content, but expect generic filenames and a sorting job.
  • Nothing works: stop. Every further write shrinks the odds, and a professional recovery service is the last resort.

On SSDs, TRIM can erase freed blocks quickly — do not wait.

FAQ

Can I recover a file deleted with rm? Often, yes — rm only unlinks the name; the data remains until overwritten. "Permanent" only happens when those blocks get overwritten, or on SSDs when TRIM erases them. Stop writing to the drive immediately for the best odds.

Why did PhotoRec rename my files? Because it never looks at the filesystem, it never sees filenames — it identifies files purely by content signatures and assigns generic names like f0021184.png. Identify recovered files by opening them, not by their names.

Can I recover files from a formatted drive? Sometimes, with PhotoRec: formatting usually rebuilds filesystem structures without overwriting most data blocks. A quick format beats a full zero-fill for recoverability.

Should I install recovery tools on the same drive I am recovering from? No. Installing anything writes to the drive and can overwrite exactly the blocks you are trying to save. Work on a dd image copy instead.

Conclusion

Three methods, three strengths. The open-file trick is guaranteed when it applies. debugfs gave byte-perfect ext4 recovery. PhotoRec gave byte-perfect recovery by content on any filesystem, at the cost of filenames. And extundelete's zero is a reminder to understand what a tool reads before trusting it: no journal, no journal-based recovery. Whichever method fits, the first step never changes — stop writing to that drive, then recover.

How this article was made

Tests run 2026-10-25 on Ubuntu 24.04 in this project's Linux VM. Scratch filesystem: 100 MiB ext4 image (mke2fs -t ext4); files written and deleted with debugfs 1.47.0, as the VM has no loop device for mounting images. Tools: debugfs 1.47.0, extundelete 0.2.4, PhotoRec 7.1. Checksums verified with md5sum against the originals for every recovered file; the open-file test used a Python process holding the file open, deleted with rm, and copied back from /proc/PID/fd/3. The extundelete procedure and journal mechanism are documented on the official extundelete site (linked above); its zero-result here is a test-setup limitation, not a verdict on the tool. No Windows or macOS tools were tested. Drafted with AI assistance; every result and checksum comes from the author's own runs on that date.