e2extract was originally created by the late Steven Fountain. Seems like he died in September 2005 and somebody replaced his whole site with an obituary. Unfortunately was also his e2extract toolkit removed; it can be still accessed via the Internet Archive though.
This page is currently a mirror of his tools with a few patches of mine.
- My patched version of his toolkit.
- The original version pulled from the Internet Archive.
The scripts are still running, I don't know if they actually work. You might also be interested in e2retrieve.
The original README:
|Ok this is what you do:|
Grab the whole contents of http://dreamscape.org/toolkit/
Run stat_inodes to make a map... find some big file, find some file with the type of 'data' (thats what the directories show up as).. whatever..
Run parse_directory_inode on the type 'data' file and if its a directory inode, You are in luck.
Backtrace through the .. entries until you locate your / inode or something important like /home or /var, whatever.
Then launch e2extract on that directory inode and eveyrthing will be recreated elsewhere. Magic.
check out the other crap i'm peddling (http://dreamscape.org/code)
This is it! e2extract - extracts lost files and recreates
from information obtained by the directory inodes, such as the original file name and location. recurses through type 1 files
(normal files) and type 2 files (directories), recreating them in a directory somewhere else.
I have written a script called parse_directory_inode in perl to analyze
Signifigant process towards my miracle ext2fs recovery!
Recovered contents and locations of files in /home: 1193744 - . || 163554 - .. || 1913380 - LOCKED || 572426
- alex || 785025 - altenra || 2109738 - alyons || 1947470 - ca || 1194510 - cider || 1717031 - clueson || 1324541 - corey || 997759 - cres || 1537216 - daddy || 1161022 - dc || 311749 - demon || 278804 - digitalkitten || 1978760 - dm || 457991 - douglas || 573728 - eah2dsct || 1358371 - edward || 802749 - enraptured || 1341009 - enthused || 1195598 - fix || 1978769 - frankie || 1259208 - granny || 1978771 - halcyon || 637850 - harsh || 753068 - imcweb || 1831594 - jason || 1358199 - jfw || 687063 - jrl || 1946438 - kaitcam || 883226 - kait || 277992 - kemuel || 1635637 - kgb || 1096409 - krs || 2060807 - kruyle || 1341550 - krzee || 1864636 - macker || 1144726 - mts || 818630 - murphy || 2209044 - mush || 1357226 - obscurus || 605553 - orb || 834975 - pandora || 1553728 - phreaky || 1227575 - precious || 2044009 - re || 1586681 - renee || 1194763 - root || 279748 - sa || 1030602 - seraphim || 2207585 - slf || 1733477 - slf.OLD || 1161848 - sloth || 1195599 - slw || 1684896 - smurfy || 279114 - someuser || 1586692 - spider || 310709 - superhanky || 1832062 - yoshi || 2027674 - yunicus ||
This tool analyzes the raw ext2 directory inode and plucks out the
names of the files contained within the directory. Also the inode number
for every file that is associated with each file name. LANDMARK
I can recover the directory structure complete with filenames!
What the fsck?! I have to manually do the job of the ext2fs driver.
is going back online in 7 days
I got my mailfile back!!!!! My stat_inodes tool is the ground floor of
beyond-hope data recovery. All I had to do was count backwards from files
that were 20 digits, 19 digits, 18 digits, etc until I got to files that
were in the 10-99 meg ballpark. I found it. I will write a mass-recovery
tool to assist in reaping all of the remaining data into by-type
"Losing 8 years of history is very motivating."
Sometimes 'I hope you have a backup *chuckle*' is the wrong approach to the
situation. This is the right way to deal with this type of
Corruption? this box was that old? whut
now?!? - after 8 years... dreamscape.org, illusion.org, compulsion.org -
gone for now - maybe not forever - who knows, really.
wrote a tool called stat_inodes in perl -
footsteps of unix necromancy. that attempts to triage what's still on an
ext2fs drive. It uses istat and icat from the new coroners toolkit (TASK)
-- it creates a garganguan huge map showing what you've still got. It
calculates the block numbers associated with inodes, wether the inode is
allocated, the size of the information referenced in the inode, the number
of blocks allocated related to the inode (each block is 1x your
blocksize), the number of links (whatever thats for), and finally what the
program guesses the block to contain, using "file magic"
54 - Y - 875 bytes, 2 related, age 1999, 1 links - ASCII English text
55 - Y - 691 bytes, 2 related, age 2000, 1 links - Bourne shell script
56 - Y - 3338 bytes, 2 related, age 1999, 3 links - ASCII English text
57 - Y - 3026 bytes, 2 related, age 1998, 3 links - ASCII English text
58 - Y - 3614 bytes, 2 related, age 2000, 3 links - ASCII English text
59 - Y - 4096 bytes, 2 related, age 2002, 3 links - data
60 - Y - 422 bytes, 2 related, age 1999, 1 links - ASCII C program text
* the old root drive is completely fucked up,
see for yourself.
* fsck reports that there are 255000 files on
the filesystem, but when you mount the drive,
there are 9841 files reported via find . | wc -l,
meaning that 240000 files (or trees) are
sitting in limbo inaccessable.
* this basicly means that the drive requires
* skeleton traffic has been redirected..
* that means i'm holding onto the mail
and you'd have to bribe me to see it
* all the content is 'gone' but still there,
* nobody gives a damn
* everythings gone - even the pictures from
99 to 2001
* starting from scratch is the only remaining
option..? or is it?
* so much for ghosts
* e2salvage might make a difference..
i got it from the BBC mini-distro.
* there is definitely a will
tools attempted thus far: debugfs, dumpe2fs, e2fsck,
e2salvage, the old coroners toolkit (TCT),
the new coroners toolkit (TASK)... the coroners toolkit
is the only thing that's been of any use! I am now
technically superior to e2fsck, dumpe2fs, and debugfs. :P
e2salvage just corrupted it more
i sortof have built my own critical file analysis toolkit in
the process of combining these.
the idea is that i'm going to cat every inode on the disk
and attempt to identify what the hell it is via "file"
icat device [inode] | file -
it shows output like this in my map..
INODE : TYPE
49758 : ASCII English text
49759 : Bourne shell script text executable
49763 : ASCII C program text
49795 : a /usr/local/bin/perl script text executable
49803 : ASCII Java program text
49873 : ASCII English text, with very long lines
1880978 : GNU tar archive
1881071 : Zip archive data, at least v1.0 to extract
1733359 : gzip compressed data, was "spam.tar", from Unix
so basicly i can guess what's in each cubbyhole.
If I find something interesting, I can get it off the disk..
icat device [inode] > newfile
icat device [inode] | less
I can look inside files without taking them off the disk, if
they are tar files by trying..
icat device [inode] | tar xvf - if it was just a tar
icat device [inode] | tar xvzf - if it was gzip'd
icat device [inode] | bzip2 -dc - | tar xvf - if was tbz2
I can also 'stat' an inode...
istat device [inode]
milk:/mnt/bin# istat img 1880977
uid / gid: 0 / 0
num of links: 1
Accessed: Mon May 14 17:43:42 2001
File Modified: Tue Jul 28 17:16:58 1998
Inode Modified: Mon Oct 23 23:50:35 2000
3770649 3770650 3770651
the cool thing is that if all the data is still there (on the
direct blocks table) you don't have to do it on each inode
associated. it will show the related blocks for you.
root@milk:/hoho# e2fsck -V
e2fsck 1.32 (09-Nov-2002)
Using EXT2FS Library version 1.32, 09-Nov-2002
root@milk:/mnt# e2fsck -v -f sdd1.backup
260060 inodes used (11%)
9104 non-contiguous inodes (3.5%)
# of inodes with ind/dind/tind blocks: 16881/317/1
3509621 blocks used (78%)
0 bad blocks
0 large files
233832 regular files
965 character device files
3409 block device files
4949 symbolic links (4947 fast symbolic links)
root@milk:/mnt# mount -t ext2 -o loop,ro sdd1.backup /hoho
root@milk:/mnt# ls /hoho
root@milk:/mnt# cd /hoho
root@milk:/hoho# find . | wc -l
This doesn't make sense at all. There are 233832 files and
16791 directories, only 9751 files show up after doing
repeated fsck's. The fucking information is there.
I'm evaluating these assumptions..
A) some of these decisions can break fsck and cause it
to halt if they arent chosen
B) things that say 'clear' may not nessicarily be a good
The following decisions were made via fsck -y..
dreamscape:/web# zgrep "\? " dsc_is_fucked.txt.gz | exclude \
"\?\?\?"|nonum |seen|sort -n
1:/lost+found not found. Create? yes
1:Bad block inode has illegal block(s). Clear? yes
1:Clear inode? yes
1:Inode # has illegal block(s). Clear? yes
1:Inodes that were part of a corrupted orphan linked
list found. Fix? yes
1:Reserved inode # has bad mode.
1:Reserved inode # has bad mode.
1:Reserved inode # has bad mode.
1:Root inode not allocated. Allocate? yes
1:Special (device/socket/fifo) inode # has
non-zero size. Fix? yes
2:Root inode is not a directory. Clear? yes
8:No room in lost+found directory. Expand? yes
18:Unattached zero-length inode #. Clear? yes
76:Deleted inode # has zero dtime. Fix? yes
79:Inode # has compression flag set on filesystem
without compression support. Clear? yes
95:Clear HTree index? yes
110:Inode #, i_size is #, should be #. Fix? yes
111:Inode # has imagic flag set. Clear? yes
119:Inode # is in use, but has dtime set. Fix? yes
135:Entry has deleted/unused inode #. Clear? yes
152:Inode #, i_blocks is #, should be #. Fix? yes
880:Clone duplicate/bad blocks? yes
2141:Connect to /lost+found? yes
3885:Inode # ref count is #, should be #. Fix? yes
dreamscape:/web# grep s\/ nonum
s/Entry \'.*?\' in .*? \(\#\)/Entry /g;