"Fossies" - the Fresh Open Source Software Archive

Member "ext3undel-0.1.6/doc/ralf.txt" (13 Jun 2008, 4873 Bytes) of package /linux/misc/old/ext3undel-0.1.6.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 #==============================================================================
    2 # R.A.L.F. (Recover A Lost File)
    3 # Syntax: $0 <filename>
    4 #------------------------------------------------------------------------------
    5 # Ralf is just a shell script that automates the manual steps required to
    6 # restore a (accidentally) deleted file from a modern ext2/ext3 file system.
    7 # For other *nix file systems there may be easier solutions - though Ralf
    8 # should also be able to handle them, as long as they work with iNodes.
    9 #------------------------------------------------------------------------------
   10 # Requires: photorec OR foremost
   11 # Requires: sleuthkit (at least fsstat, dls and fls from that package)
   12 #==============================================================================
   13 
   14 Introduction
   15 ============
   16 The concept of Ralf is based on an article I found in the InterNet - while
   17 looking for a way to recover (accidentally) deleted files from Ext2/Ext3
   18 file systems (see
   19 http://www.lonerunners.net/blog/archives/1056-How-to-recover-data-and-deleted-files-from-Ext3-partitions.html)
   20 Sure, almost everybody seems to be quite sure that it is impossible to undelete
   21 such a file - and so almost everybody is wrong, as the few exceptions prove.
   22 There are excellent tools available to forensic research, which can restore
   23 almost everything.
   24 
   25 To mention the tools first: PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec)
   26 is far the best I found - it supports the widest range of file types, and is
   27 available on *nix and *dows system as well. The same task is fulfilled by
   28 foremost (http://foremost.sourceforge.net/), just less file formats are
   29 supported. And then there is sleuthkit (http://sleuthkit.org/), a whole
   30 forensic toolbox...
   31 
   32 Concept
   33 =======
   34 On the "good old" FAT system, undeleting was as easy as edit the File Allocation
   35 Table, changing the first character of the deleted file name from "?" to
   36 something else - and the file immediately re-appeared visible in the file
   37 system. With Ext3, this is not even nearly as easy: When you delete a file in an
   38 Ext3 file system, the connection between the "MetaData" (Filename, CreationDate,
   39 which file system blocks are occupied by this file, and the like) and the
   40 "Content" (i.e. the real data) is destroyed and lost - so you no longer can
   41 look it up in any "table"...
   42 
   43 The web page mentioned above describes a way how it can still be rescued: As
   44 long as it was not overwritten, both the iNode and the data blocks are still
   45 available - they are just no longer connected with each other. If we don't
   46 know the file name and its location any longer, tools like PhotoRec and
   47 foremost can scan all (free) data blocks within the file system for known
   48 signatures, to identify the file type and, hopefully, restore the file. But
   49 on a large disk, this will restore a lot of files - so we somehow need to
   50 restrict the search area.
   51 
   52 If we know the file name, we can do so - and this is where Ralf (and the
   53 concept from that web page) come into play:
   54 
   55 fls   : This helper scans the iNode information, and its output contains
   56         things like the file names, creation/modification time, etc. together
   57 	with the iNode holding this information
   58 fsstat: iNodes are organized in groups, and each group has a given area
   59         assigned on the hard disk to store the real data. So if we know
   60         our iNode, we can use fsstat to find the group it belongs to, and
   61         grep a range of file system blocks the file must have been stored to.
   62 dls   : We use this tool to extract the blocks we just found to a file
   63         system image - and then we can use this image to retrieve our lost
   64 	file from (and won't find too much other files as a side-effect)
   65 
   66 Now, instead of half a Terrabyte to scan for, we have limited this to a few
   67 megabytes (or even less). We can use PhotoRec or foremost on the image file
   68 created by dls, and as a result we find e.g. 6 files to decide between
   69 (instead of 6.000 otherwise). Still, the files NAME is lost: Imagine we
   70 searched for "example.txt" - but as a result, we got back 6 *.txt files.
   71 Since we do not know which of them belonged to what iNode, we cannot
   72 automatically tell which is the file we wanted to restore - but that's
   73 nothing of a problem, compared to the alternative: The file lost completely...
   74 
   75 R.A.L.F.
   76 ========
   77 So what does Ralf do? It simply automatizes the steps you also could do
   78 manually:
   79 * find the correct file system and adjust the file name, so we know how to
   80   call fls and what to search for in its output
   81 * evaluate the output of fls, call fsstat and find the match
   82 * call dls and extract the correct data blocks
   83 * call PhotoRec / foremost and extract the content of the image
   84 
   85 So instead of doing all those steps manually, you just call Ralf with the
   86 name of the file to recover - and Ralf does the job. The only thing left to
   87 you is: Evaluate the results, and rename your file.