.:ms²:.   Your IP: 54.237.197.160 
ms²

e2extract

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.

e2extract-toolkit-20061119.tar.bz2
My patched version of his toolkit.
e2extract-toolkit-20040223.tar.bz2
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 directory structure 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 directory inodes!!
    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 progress.

    I can recover the directory structure complete with filenames!
    DSC is going back online in 7 days

    What the fsck?! I have to manually do the job of the ext2fs driver.
    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 directories.

    "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 problem.

    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.

    I 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
      unix necromancy
    * 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,
      somewhere.
    * 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
    
    ..slf@dreamscape.org
      (925-895-1500)
    
    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
      inode: 1880977
      Allocated
      Group: 115
      uid / gid: 0 / 0
      mode: -rw-------
      size: 10989
      num of links: 1
    
      Inode Times:
      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
    
      Direct Blocks:
      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
      [snip snip..]
      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
       16791 directories
         965 character device files
        3409 block device files
          11 fifos
         967 links
        4949 symbolic links (4947 fast symbolic links)
          94 sockets
    --------
      261018 files
    root@milk:/mnt# mount -t ext2 -o loop,ro sdd1.backup /hoho
    root@milk:/mnt# ls /hoho
    lost+found
    root@milk:/mnt# cd /hoho
    root@milk:/hoho# find . | wc -l
       9751
    root@milk:/hoho#
    
    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
          idea.
       
    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.
         Clear? yes
       1:Reserved inode #  has bad mode.
         Clear? yes
       1:Reserved inode #  has bad mode.
         Clear? yes
       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
       2:Salvage? 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
       275:Clear? yes
       880:Clone duplicate/bad blocks? yes
       2141:Connect to /lost+found? yes
       3885:Inode # ref count is #, should be #.  Fix? yes
       5095:Fix? yes
       dreamscape:/web#
       
    dreamscape:/web# grep s\/ nonum
        s/\d+/\#/g;
        s/Entry \'.*?\' in .*? \(\#\)/Entry /g;
    

     .:Copyright (c) 1997, 1998-2014 Malte S. Stretz:.