[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Undelete?

Andreas Thienemann writes:
> Stephen C. Tweedie wrote:
> > but you ought to find _some_ deleted inodes. 
> Nope. Even the newer debugfs Version 1.20-WIP from the 17th of January
> says "0 deleted inodes found".

I have noticed this once as well, when I wanted to try using debugfs to
restore a file.  I didn't care much at the time, because I could recover
the file from a backup.  Some day I may _not_ have a backup, so it would
be nice if debugfs worked...

> > I won't have any time to do much debugging of debugfs soon, 
> > unfortunately.
> So you think it is a problem of debugfs?

Probably.  Just checking now on a test filesystem:

# cp /etc/hosts /mnt/boot
# rm /mnt/boot/hosts
# sync
# debugfs /dev/vgboot/lvboot
debugfs 1.20-WIP, 17-Jan-2001 for ext3 FS 0.5b, 95/08/09
debugfs:  lsdel
0 deleted inodes found.
 Inode  Owner  Mode    Size    Blocks    Time deleted
debugfs:  stat <14>
Inode: 14   Type: regular    Mode:  0644   Flags: 0x0   Generation 3763266686
User:     0   Group:     0   Size: 0
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 0
Fragment  Address: 0   Number: 0    Size:0
ctime: 0x3aaffc0e -- Wed Mar 14 16:17:34 2001
atime: 0x3aaffc0c -- Wed Mar 14 16:17:32 2001
mtime: 0x3aaffc0c -- Wed Mar 14 16:17:32 2001
dtime: 0x3aaffc0e -- Wed Mar 14 16:17:34 2001

It seems to be some sort of artifact with ext3 - lsdel does not list
files that have zero blocks (no point in recovering them), nor files
whose blocks are marked as in-use by another file (even though in
some cases this might be useful).  It appears that on deleted ext3
files, the i_blocks field is set to zero on a deleted file, making
it impossible to recover.  On ext3, the direct and indirect blocks
are also zeroed out (I checked with "od" after verifying that they
were stored to disk with debugfs), so there is basically no easy way
to know where the blocks are.

I tried the above test on ext2, and the file showed up with 1 block,
and lsdel works - the file shows up, the blocks are still there, etc.
Must be something to do with how ext3 deletes files - does it truncate
them first or something?

If you _really, really_ need to get this file back (i.e. your life
depends on it), you could start by finding the inode of the directory
where the file was (dumpe2fs, or "ls -i" on an R/O mounted fs).  Then
use dumpe2fs to find which group the directory was in, and which blocks
are free in that group.  The deleted file will _probably_ start in the
first group of 8 free blocks in that group.  If you have deleted a lot
of files after your important one, then it will be hard to find.

If the file is small (i.e. less than 8 * blocksize), then you can try:

   dd if=/dev/X of=/tmp/file bs=<ext3blocksize> skip=<free_block> count=X

_may_ at the outside chance get your file back.  Try this with several
block_numbers, using ones that dumpe2fs reports as free.  X is the
approximate size of the file in blocks (you may want to start with a small
X to see if you find the beginning of the file).  If it is larger than
8 blocks, it may be hard to find all of the parts - they will be in blocks
_after_ the previous block on disk, never before (I think).

If the file only existed for a few seconds, it may not have made it to
the disk at all.

Cheers, Andreas
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]