From: "Stephen C. Tweedie" (
Subject: Re: data recovery on ext3-partition
Date: Wed, 4 Sep 2002 13:45:36 +0100


On Wed, Sep 04, 2002 at 09:35:50AM -0300, Alexis S. L. Carvalho wrote:

> Thus spake Stephen C. Tweedie:
> > Journalling requires the delete to be done immediately on disk for
> > various subtle reasons that I'll go into again if there's interest.
> > :)
> I'm interested :) - though I'll understand if you just tell me to
> search the archives.

Truncate transactions (like the ones implicit in delete) can get really large. The filesystem has bounds on the size of a transaction, but there are essentially no bounds on the amount of metadata a truncate can modify. So to fit things into the limited space in the journal, ext3 needs to be able to split a truncate over multiple transactions.

And that is not possible unless we record, on disk, the incremental progress of each bit of the truncate. If we didn't record progress, then if we crashed in the middle of the truncate, the metadata on disk would be in a mess, and ext3 is supposed to prevent that!

But a side-effect of keeping the on-disk progress of the truncate coherent is that once the truncate completes, all record of the original data has been wiped out.


From: Federico Sevilla III (
Subject: Re: [plug] rm --means goodbye?
User-Agent: Mutt/1.4i
Date: Fri, 16 Aug 2002 14:55:08 +0800

On Fri, Aug 16, 2002 at 02:14:33PM +0800, Dudley F. Ca?as wrote:
> Hi sorry for cross posting this message, but our friend Marvin, I
> think is in trouble :). His question is that, if a file is accidentaly
> delete does this mean goodbye or is there another way we can recover
> those deleted files.

I've heard of the ext2 undelete tools[1], but have never actually used them.


> I thinks help is much needed heheheehe!

Unfortunately I don't think any of our help will be of much use ...

> BTW he's using MANDRAKE 8.2 on ext3f

... because Stephen Tweedie himself says:

There is no automatable way. Your best chance is probably to use a disk editor to search for the freed disk blocks containing the data.

and Theodore Ts'o later ends(?) the thread with:

Midnight's [Midnight Commander's] undelete has the same limitations as debugfs, since it's using the same approach.

The real problem is that ext3 isn't saving the block numbers in the inode after the inode is deleted, which means that the debugfs and midnight commander undelete schemes can't work.

If you use e2image to save snapshots of the filesystem metadata, you can use that to recover from deleted files that existed before the e2image metadata snapshot was taken. The real answer though is to keep regular backups of your data....

Feel free to read this entire thread[2] (June 2002) from the ext3-users mailing list.


The best of luck.

--> Jijo

Federico Sevilla III :
Network Administrator : The Leather Collection, Inc.
GnuPG Key ID : 0x93B746BE

Quoting the Ext3 FAQ,

"Q: How can I recover (undelete) deleted files from my ext3 partition?

A: Actually, you can't! This is what one of the developers, Andreas Dilger, said about it:

In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks he inode as 'deleted' and leaves the block pointers alone. Your only hope is to 'grep' for parts of your files that have been deleted and hope for the best.

It turns out that there are some ways to, sometimes, undelete files using information from /proc:

Date: Thu, 16 Oct 2008 19:18:02 +0100
From: Jimmy O'Regan (
To: The Answer Gang (
Cc: "J.Bakshi" (
Reply-To: The Answer Gang (
Subject: Re: [TAG] deleted file recovery

2008/10/16 J.Bakshi (

> I generally work with Linux terminals. Frequently, I have to do "rm" to delete
> files/folders that are not required, any more. And this actually raised a
> question in my mind: What to do if some point of time I need a file/folder
> that was deleted a few minutes ago? I have googled a lot, but have
> not found any open source tools that can recover the deleted ones. Testdisk
> is there, but is totally different. There are some proprietary GUI-based
> tools available, but I am looking for a CLI tool or technique that
> can practically recover the deleted file/folder.

You don't want testdisk; you want the author's other tool - PhotoRec ( It scans for deleted files based on their signatures, and by default recovers all deleted files on a disk image.

I've used it a few times, and it works quite well.