Path: utzoo!attcan!uunet!bu.edu!orc!decwrl!sdd.hp.com!hplabs!hpda!hpcuha!hpcuhd!scotta
From: scotta@hpcuhd.HP.COM (Scott Anderson)
Newsgroups: comp.sys.hp
Subject: Re: undeleting files....
Message-ID: <106910004@hpcuhd.HP.COM>
Date: 31 Jul 90 18:11:17 GMT
References: <23848@boulder.Colorado.EDU>
Organization: Hewlett Packard, Cupertino
Lines: 60


    Like everyone else has said, unless you took precautions against the
disk space getting reused, the files are probably gone.  My contribution
to the subject is how to avoid fsdb...  I'll warn you however, my method
is slow, relies on you to remember a string from the file that will be
fairly unique on the entire disk, is not idiot proof, you need to be
root if your device files are set up correctly, works well only on ascii
(or other recognizable data) and that in order to reliably work will
require access to a disk other than the one that contains the file.  The
advantage is that you're a lot less likely to screw up your file system
and that you don't have to have an intimate knowledge of the file
system.

    Ok, here goes: I use a combination of fgrep and dd to grab the file.
First you need to find the block address of the file:
	fgrep -b 'known text string from removed file' /dev/rdsk/0s0
Replace /dev/rdsk/0s0 with the character special device for the disk
that contains the removed file.  Watch the output and identify which
occurrence occurs in the removed file.  BTW, don't expect to be able to
fgrep an entire disk instantaneously :-).

    Now that you've got the disk address (e.g. 12345), now use dd to
snag a bunch of blocks around that address in order to make sure that
you get the whole file:
	dd if=/dev/rdsk/0s0 of=file_on_another_disk skip=12340 count=11
In this example, I knew that the file was around 2k long, so I wanted to
grab 5 blocks (2.5K; 1 block = 512b) of slop before and after the
address that was reported by fgrep (skip=address-slop; count=2*slop+1).
Instead of /dev/rdsk/0s0, you should use the same character special file
you had fgrep work on.  Make sure that you don't flip the if= and of=
around: can you say trash the file system?  Saving the output is where
you need a second disk (or I guess you could just dump the stuff out to
a tape).  If you put the output on the same disk as your removed file,
there's a chance (I don't know the probability) that your output will
blow away the data you're trying to recover.  One last thing about dd:
it was designed as a tape utility; as such it doesn't use seek to get
the block you specify with the skip parameter: it just keeps reading
until it's read the specified number of blocks.  This means that you
shouldn't expect this operation to go any faster than the fgrep did.
For those advanced users, you can use a larger block size (bs=) in order
to speed it up; make sure you recalculate skip= and count= based on the
new block size.  If someone knows a better way or has written the short
program necessary, speak up.

    The file that you have now will have a bunch of extraneous stuff on
both ends of it (probably nonASCII).  Go in with an editor and remove
the stuff from both ends and you've got your file back.  If the editor
you want to use doesn't deal with nonASCII data very well, you may want
to pipe your file through cat -v before editing it.

    I suppose I should add that I'm not speaking for HP and that I have
nothing to do with HP-UX except that I use it as a tool to get my job
done.

    Scott Anderson
    An RTEsian and proud of it...
                                                 Hewlett-Packard
    ARPA: scotta%hpdsorte@hpsde.HP.COM           Data Systems Operation
    UUCP: hpsde!hpdsorte!scotta                  11000 Wolfe Rd.  MS 42UN
    408-447-5219                                 Cupertino, CA  95014