----------------------------------------------------------------
	This file is supposed to guide you in unerasing files.
I wrote an awesome guide last week, but erased it, so I'm going
to breeze through things and probably assume too much, but I
really don't have time to do this again.
----------------------------------------------------------------

0) Read the introduction to the minix file system included in
   the doc directory, I am not going to explain terms in this
   document.

   Read the lde man page to get familiar with the lde program.

   Read this document all the way through forty-two times,
   (well at least once).

   Play with lde a few times before you really do lose some 
   data, just to get familiar with the file system and the
   program to see what you can expect, try recovering some
   files which haven't been deleted or delete a junk file
   and recover it.

1) There are a few things you can try to unerase a file:

    *** Always *** unmount the file system with the erased 
    files as soon as you realize what you have done.  This
    just prevents any programs from writing over any
    important information.

   A) You can search all the unused inodes with lde to 
   find an inode with size/date/file characteristics 
   similar to the one you erased.  Start lde, hit 'i'
   to enter inode mode, 'u' to toggle the unused/all
   inode search, then UP/DOWN to page through all the 
   inodes, this can take a long time.  When you find one
   which looks good 'B' (not 'b') will display the first 
   block in the file so you can see if it looks familiar,
   (too bad for binaries).  When you have what you think
   is the right inode, hit 'R' (not 'r') to jump to
   recover mode, skip ahead to step 2.

   B) If you don't have an inode entry, you can search
   the disk for data with grep or lde.  lde is slow and
   only looks for gzip files, grep requires a little 
   interaction.

   To grep a file system, use "grep -b STRING /dev/?????"
   Fill in STRING with a regex string which you hope to 
   find and /dev/???? with the device you want to search.
   You will probably want to dump the output to a file
   as it will be full of binary characters, then use 
   an editor to search the file for byte offsets.  Each
   match will be preceded by a number and a ':',
   take this number, divide it by 1024, and this is the
   block you want to start looking from.

   When you use lde to search a file system, it will report
   gzipped files and indirect blocks.  The
   indirect blocks are really just very bad guesses
   (actually, in my tests, it has only output indirect
   blocks, but it has missed a lot of them, look in the 
   source for more information).
   
   Anyhow, the point of all this searching is to find the
   seven direct blocks, the indirect block, and the double
   indirect block.  This may not be as hard as it sounds,
   most file systems are not horribly fragmented and
   there is a good chance that these may be close to 
   each other.

   DIRECT BLOCKS:  you have to get these in order.  The
   first seven blocks of the file may be somewhere on the
   file system.  You can use the 'u' option to page through
   only the blocks which are marked unused.  When you find
   one, mark it's place with the correct key '0'-'6' 
   corresponding to it's placement in the file.

   INDIRECT BLOCK: sometimes these stand out pretty well
   and this is where the bulk of the data will be.  (You will
   be well off if you can still use this data even if you
   are missing the first 7k of the file).  Indirect blocks
   contain low/high byte pairs which point to other blocks.
   When visually searching the disk, you should expect to
   see a lot of high bytes with the same number, and a lot
   of low bytes which go in sequence.

   00 65 01 65 02 65 03 65 : 04 65 05 65 06 65 07 65 .A.A.A.A.A.A.A.A   

   or

   65 00 66 00 67 00 68 00 : 69 00 70 00 71 00 72 00 A.B.C.E.F.G.H.I.

   These will be most evident when one or the other is filled 
   with unprintable characters as in the above examples.  (Sorry,
   they should be in hex where something other than 65 is 'A'
   but you get the idea).

   When you find the indirect block, mark it by hitting '7'.

   DOUBLE INDIRECT BLOCK: If the last entry in the indirect block
   is not 00 00, you will also have to find an indirect block.
   The best place to start looking is at the last block pointed 
   to by the indirect block, go to this block (remember it is
   in low/high order, if the entry is 01 02, you want to go to
   block 0x0201).  The indirect block looks just like a 
   direct block, but it will most definitely end with a bunch
   of zeros.  When you find something that looks like the 
   double indirect block, jump to the first block indexed by
   the double indirect block and see if it looks like an indirect
   block, if so, it's probably it.  If it doesn't blatantly not
   look like and indirect block (i.e. it's most definitely
   your mailbox) check some of the other blocks which are indexed.
   Even if it is your mailbox, it might be the right block,
   just overwritten.  If the rest of the blocks indexed look 
   like indirect blocks and you can live with 1k of garbage 
   somewhere in the center of the file, give it a try.

   When you find the indirect block, mark it by hitting '8'.
   Now that you have marked all nine blocks (the header should
   display the numbers 0-8 which started out as '-'s), hit
   'r' to go to recover mode.

2) Recovery mode:

   The screen should show those blocks which would make up an
   inode entry for the file.  None of these blocks should be
   the same (unless they are zeroes which indicate unused 
   blocks).  Also they must be contiguous, you have to fill
   in all seven direct blocks, then the indirect, then the
   double indirect.  lde does not check either of these,
   holes will be regarded as the end of the file, duplicates
   will be written out twice.

   To check the recover-ability of a file, hit 'c', this
   will go though and check that no blocks in the chain are
   marked as used.  There is a chance that they could have
   been used and freed, but this will not show up in the 
   test.  A message will be displayed in the trailer 
   window indicating the recover-ability of the file.

   To recover the file, you should have enough space to 
   write the file on another partition.  Do not write it 
   to the partition with the erased file as the contents of
   the file may be erased before it is recovered.  To
   recover the file, hit 'r' which will prompt you for
   a file name (hitting return defaults to ./RECOVERED.file).
   If things went well, this file will have a copy of the
   erased file, but it will have some garbage at the end
   (there is currently no way to specify the file size,
   so the last block will be written out in full which may
   add 1k of garbage to the end of the file).

3) Other things to try, and preventative maintenance:

   A) To recover directly with an existing inode, you can 
      change the disk entry with bpe (available on tsx-11).
      You can use lde to find the inode and the block 
      with the proper directory entry, then use bpe to
      point the/a directory entry to that inode.  This
      is not endorsed by me or anyone, it is just a 
      suggestion and probably a good way to trash a
      full file system (or not).  You may have to modify the
      number of links in the directory's inode, mark
      blocks used/unused, and do a lot of other work 
      which fsck might be able to help you with.

      One day (see the TODO file), disk writes will be
      a feature of lde, but for now it is read only, 
      writable only to the recovery file which had
      better be on another partition.

   B) Backup you system regularly (Sorry, but it is
      really your best defense).

   C) do a "ls -iRa / > /.unerase" every so often
      (daily, hourly, ?), this will list all files and
      their inodes to the file, when you do erase something,
      you can look up the inode (which it occupied at one
      time in its life) and possibly get a jump on the
      recovery process.
 
   D) If you want to recover things one block at a 
      time, you can use "fsck -d### >> output.file" to
      append block number's ### contents to output.file.
      This might be useful if you can't find an indirect
      block.  As of now, the user cannot build his
      own indirect block, see the TODO file.
   
   E) When you are recovering a file, write down everything
      you do.  Write down the bogus inode entry before 
      you do the file recovery in case it comes out close
      and you have to redo it.

   F) These are some off the wall alternatives, if you
      really really want your file back.  

      Is there another erased copy of the file somewhere?
      Might some /tmp file have been recently erased or
      even still be there?

      What about searching the swap partition for text? 
      How about /dev/mem, dump it to a file otherwise 
      the cache from other file operations will probably
      get to your data first.  Does the act of dumping
      it use cache space?

      Be creative, it's probably gone forever, but it 
      is always more fun to hack around reconstructing a
      file than redoing the work it took to create the
      file. :)
