The ext3undel project offers a collection of scripts to help you recover files from ext2/ext3 file systems, where you (accidentally) deleted them from.
Though most pages in the InterNet state it is impossible to undelete such files, this is simply wrong. Just think of all the forensic people - it is their daily work. Correct is: It is not that easy as to simply take them out of some trash folder. The ext2/ext3 file system stores the MetaData (i.e. the file name, its size, creation/modification date, etc.) in its "iNodes" - together with the information in which file system blocks the real data is stored. When you delete a file, this connection between the iNode and the data blocks is broken, i.e. the iNode forgets which data blocks belong to the file - and both, iNode and data blocks, are marked as free. Still, the information stays there until it is overwritten.
Due to this fact, tools like PhotoRec or foremost can scan the "free" blocks for "signatures", and restore the files data (there are "significant bits" for most file types - just open some in an ASCII viewer, and you will note the "JFIF" in the beginning of JPG files, "FLV" for Flash Videos, "PK" in ZIP files, and so on). But since the connection to the iNode is lost, they cannot tell the real name of that file - and thus cannot restore a "certain file" - it's either all or nothing, and for a large disk there may be many files restored (which would take you hours to sort out).
However, iNodes are organized in groups, and each of these groups have a known group of data blocks they keep the information for. So if we could figure out the iNode our file occupied once, we can restrict our restore process to that group of blocks - that is what R.A.L.F. does with the help of Sleuthkit: The fls executable lists up all iNodes together with the MetaData (which we grep for the file name, so we get the iNode number). fsstat lists up all iNode groups together with their associated data blocks (which we grep for the iNode number retrieved with fls). dls extracts the specified data blocks from the file system, and stores them to an image. Now we can tell PhotoRec (or foremost) to scan that image (instead of the complete file system), and our result is much closer to what we seek.
Opposite to R.A.L.F., G.A.B.I. is designed to get all files from a given disk (partition). You might not need G.A.B.I., but could use PhotoRec or foremost directly instead - all G.A.B.I. does is to save you from selecting the command line switches/options, and ensuring that you recover to a disk/partition other than the original data are on, to avoid more destruction before the recovery has been done.
· Photorec or foremost
What's New in This Release: [ read full changelog ]
· source partition selection in gabi was missed to fix
· added warning to ralf if source file system is not ext2/ext3
· fixed a little problem with photorecs freespace/wholespace parameter
· filetypes.* have neither been correctly installed nor referenced