	I imagine that most of the people initially using this
package will be the ones who have recently deleted something.
After all, that's what finally inspired me to learn enough about
the different file systems to write this package.  Undelete
under unix really isn't that hard, it really only suffers the
same problems that DOS undelete does which is -- you can't
recover data that someone else has just overwritten.

	If you are quick and have very few users on your system
there is a good chance that the data will be intact and you can
go ahead with a successful undelete.  I don't recommend using
this package to undelete your /usr/bin directory or really any
directory, but if you have trashed a piece of irreplaceable code,
undelete is where it's at.  If you can reinstall or have recent
backups I'd recommend you try them.  But it's up to you,
besides, sometimes playing with undelete for a while is a lot
more fun than going back and recoding a few hours worth of lost
work.

	Before I tell you how to undelete stuff, have a look at
doc/minix.tex (or the ps or dvi version).  Even if you aren't
using a minix file system, it will get you used to the terms and
the general idea behind things here.

These are the steps for a successful undelete:

1) Unmount the partition which has the erased file on it.  If
you want to, you can remount it read-only, but it isn't
necessary.

2) Figure out what you want to undelete.  If you know what kind
of file you are looking for, finding it will be a lot easier.
There are a few ways to look for file data.

	lde supports a type search and a string search for data
at the beginning of a file.  Currently, the supported types
include gz (gzip), tgz (tarred gzip file), and script (those
beginning with "#!/b").  When you run lde in these mode, it will
report a block (and inode if you are lucky) where a match was 
found.  Take this inode number and go to step (3).

	If lde doesn't report anything on its own, or the search
detailed above does not suit your needs, you can use grep to
search the partition for data and pipe it through lde which will
attempt to find a block and inode again.  The script grep-inode
is well suited for this.  The recommended procedure is (all this
can go on one line -- the '\' indicates continuation):

   grep -b SEARCH DEVICE | awk '{FS = ":" } ; {print $1 }' | \
	 lde ${LDE_OPT} --grep DEVICE

	If none of these search methods are productive, you can
page through the disk with an editor (emacs /dev/hda2) or the
preferred choice might be to page through it with lde.  Fire up
lde and go into block mode (hit 'b') then use PG_UP/PG_DN to
flip through all the blocks until you find one you like.
Hitting 'l' while displaying the block will attempt to find an
inode which references the block.

3) If you have an inode number, things are looking good.  Go
into inode mode and display this inode.  Then hit 'R' to copy
the inode information to the recovery block list and enter
recovery mode.  Now hit 'R' again and lde will prompt you for a
file name.  Make sure you write it to a file system other than
the one which the deleted file resides on or you will probably
overwrite it as you go.  One day, when lde supports disk writes,
it will be able to undelete the file to its original location,
but for now this is safer.

	If you were unable to find an intact inode, things are
going to be tough.  You will have to find all the blocks in the
file in order.  If your disk is relatively unfragmented, you can
hopefully find everything in order or close by at least.
Currently, you have to tag all the direct blocks, then find the
indirect blocks and tag them.  If the indirect block was wiped
or you are unable to find it, under this system, you will have
to restore things filling in all the blocks as direct blocks.
under minix, this means you can tag N direct blocks, write them
to a file, untag the direct blocks, pick N more, append them to
the last file and so on and so on.  I would imagine that this
would really suck and there is probably a better tool for doing
this than lde.

4) The recovered file will be a little larger than the original
as the last block will be padded with zeroes.



