I just pressed the Enter key on the file delete confirmation dialog, and removed my code which I was working on for 3 hours. In fact I had made such a mistake before and had no results searching “Ext3 Recovery / Ext4 Recovery …”. But this time, a new project named extundelete appeared which claims to extract file metadata from the file-system’s Journal.
I tried to extract and compile it by just typing “make” and found that ext2fs library is missing, so I installed ext2fs-dev package using the following command (I’m using Ubuntu 9.10) :
sudo apt-get install ext2fs-dev
Then typing “make” in the src folder, presents you the binary file named “extundelete”. You can run it like this :
No action specified; implying --superblock.
Usage: ./extundelete [options] [--] device-file
--version, -[vV] Print version and exit successfully.
--help, Print this help and exit successfully.
--superblock Print contents of superblock in addition to the rest.
If no action is specified then this option is implied.
--journal Show content of journal.
--after dtime Only process entries deleted on or after 'dtime'.
--before dtime Only process entries deleted before 'dtime'.
--inode ino Show info on inode 'ino'.
--block blk Show info on block 'blk'.
--restore-inode ino Restore the file(s) with known inode number 'ino'.
The restored files are created in ./RESTORED_FILES
with their inode number as extension (ie, inode.12345).
--restore-file 'path' Will restore file 'path'. 'path' is relative to root of
the partition and does not start with a '/'
(it must be one of the paths returned by --dump-names).
The restored file is created in the current directory
--restore-files 'path' Will restore files which are listed in the file 'path'.
Each filename should be in the same format as
an option to --restore-file, and there should be one per line.
--restore-all Attempts to restore everything.
-j journal Reads an external journal from the named file.
-b blocknumber Uses the backup superblock at blocknumber when
opening the file system.
-B blocksize Uses blocksize as the block size when opening fs.
The number should be the number of bytes.
It seems that running the program with –restore-all, should restore all possible files. Like this :
ali@Velocity$ ./extundelete /dev/sda6 --restore-all
But that option gave me some temporary, hidden and some useless config files over my home folder. I was thinking of rewriting the code …
Suddenly I found that, extundelete supports another option in which you can specify the inode number of your file, and it will bring it back … 🙂
Looking at manual of the “ls” command you’ll find that running “ls” with -i parameter will give you the inode number of files in a directory. I tried to find a range for inode files around the deleted file and search for all files in the range …
ali@Velocity:~/projects/Monko-MovieQuiz/Source/IMDBot/src$ ls -i
It seems that most of the files are in the range of 7824xxx, so searching the range of to 7824000 to 7824999 might be a good idea (take a look at the following bash code snippet) :
for((i=7824000; i<7824999; i++)); do
./extundelete /dev/sda6 --restore-inode $i ;
I got 7 deleted files in this range (inside the RECOVERED_FILES directory), and one of them was my deleted python code ! And I spent my time on writing this article instead of rewriting the code 😉