In message <9307141534.AA02630@sws1.CTD.ORNL.GOV> I wrote:
>Yes, I know it's impossible...but I'd like to try anyway.
>
>A Very Important User here lost a file and wants it back very badly.
>He was editing the file in vi (first mistake) and got some kind of
>"bad file number" error when he tried to write it out, so he did a
>":q!" (second mistake). To his horror, he discovered the file had
>been zeroed out. He fsck'd the disk (third mistake?), but that didn't
>help. His only backup of the system is two years old (zeroth
>mistake).
>
>He eventually got in touch with me, and I asked the obvious questions,
>looked for a backup in /tmp & /usr/tmp, and explained the reasons why
>recovering a lost file is essentially impossible. Nonetheless, he
>wants me to attempt to scavenge the disk and recover whatever pieces,
>if any, remain.
>
>He's running SunOS 4.1.{2|3} on a SPARCstation.
>
>The nature of the file is such that if I could load it into emacs I
>could pretty easily find and recover whatever pieces remain.
Most of the responses centered around reading the disk device using dd
and piping the output to grep, strings, or less to look for the file
in question.
Dan Stromberg (strombrg@uci.edu), for example, wrote:
>dd if=/dev/sd_whatever bs=32k | grep some_string_that_is_only_in_that_file
>
>If that turns up a hit, use a pager, like less, or hack together a
>little C program, that'll isolate that segment of text, from all the
>gibberish. There's no guarantee that the blocks of the file will be
>contiguous (though cylinder groups seem to lessen the probability of
>scattering), if they're there at all, but there's a fairly good
>chance, if the disk isn't highly active, that some of the blocks will
>still be there.
Adar Wesley (adar@math.tau.ac.il) suggested:
>We ran into this bug in vi a few times befor. One thing you didn't mention,
>which might work is vi -L to list saved files, and then vi -r <filename>, to
>restore a file which was saved when the editor died.
[We'd tried that.]
Dani Flexer (dani@mennen.com) had a nice step-by-step approach:
>1. Do not touch the partition. Especially do not write to it.
>
>2. Do "strings /dev/rsd3g > /foo/bar". If you do not have room on any
>disk for this, you can dump it to tape or something.
>
>3. Ask him for some keywords from the file.
>
>4. Edit /foo/bar (split it first if needed), look for the keywords,
>find the scattered disk pages of the file, paste them together and give
>the man his file back.
>
>5. Ride into the sunset. (but first lecture him on the importance of
>backups, not the he needs it now.. :-)).
>
>A few words of explanation:
>
>The file system on the disk does not do anything to the pages of
>deleted/truncated/overwritten files except mark them as free and stick
>them in the free list. Until another file needs a page, the original
>page will remain in its previous state. Only problem is, no way to
>access it through the file system, hence the use of the partition's
>driver, that looks at the whole partition as a sequential file.
Charles McGrew (mcgrew@cs.rutgers.edu) had another idea:
>PS - BTW, there isn't a .nfsXXXXX-copy of it, by chance? (I don't
>remember the save-sequence of vi, but emacs will occasionally leave
>behind such things, which have come in handy on occasion...)
[I don't think he's using NFS, but I didn't think of this.]
Thanks to the above respondents and the others I didn't quote in the
summary. The next time (despite our best efforts to encourage safe
computing, there *will* be a next time) I'll be more prepared to deal
with it. Maybe this should be in the Sun admin FAQ...
-- Dave Sill (de5@ornl.gov) Computers should work the way beginners Martin Marietta Energy Systems expect them to, and one day they will. Workstation Support -- Ted Nelson
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:00 CDT