Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!racerx!ken
From: ken@racerx.UUCP (Ken Hardy)
Newsgroups: comp.unix.questions
Subject: Re: undelete ?
Summary: seem to remember a review ...
Message-ID: <572@racerx.UUCP>
Date: 15 Apr 91 19:03:27 GMT
References: <26542@adm.brl.mil> <1991Apr12.072931.23362@casbah.acns.nwu.edu>
Organization: Bridge Information Systems, St. Louis
Lines: 54

In article <1991Apr12.072931.23362@casbah.acns.nwu.edu>, navarra@casbah.acns.nwu.edu (John 'tms' Navarra) writes:
> In article <26542@adm.brl.mil> rol@grasp1.univ-lyon1.fr (Paul Rolland) writes:
> >In his message, msc%SUN2.NCKU.EDU.TW@VM.TCS.Tulane.EDU said :
> >> 
> >> Dear Netters :
> >>       Is there any tool which can be used to undelete UNIX files ?
> >
> >   I'm afraid there's not such a tools... Sorry for you :(
> >	Paul
> 
>     NOT TRUE!! There is entomb which I know is available on Purdue computers.
> 
>         but besides that -- some systems set up a directory which keeps removed
>  files for a coupla days until they are deleted. Also, if your sysop takes 


I seem to remember a review in Unix World or Unix Review, or some such
place, of a set of tools that 1) do _not_ use a replacement for rm that
moves the files to a temporary directory to be deleted later by cron, or
2) involves kernel patches as suggested in some other posts.
Unfortunately, I cannot find the review on the covers of the magazines
in my stacks, and I'm not going to go paging through them.  If I recall
correctly, the utility in question actually find the i-node list for the
file and undeletes it.  It did not have 100% success, of course, but
could be better than nothing.  Also, if I remember correctly, for text
file, it gives the user the choice of which inodes to include if it is
unsure because of subsequent file system changes; the user can read the
text in question and choose what to include in the reconstructed file.

The claims made for it were quite impressive, though it seemed like a bit
of voodoo when I thought about what it must do.  Playing with the raw
disk partition seems a little spooky, introducing the potential for some
really interesting bugs, particularly when in multi-user mode.  But less
spooky to some, perhaps, than modifying the kernel.

Personally, I use a shell function that moves the files off to a
temporary directory of my own devising.  Cron cleans it up after me.  If
my disk gets too full, I browse through it cleaning out things I know I
don't care for.  I also use that directory for work I know is temporary,
since it gets cleaned out automatically.  I always have had a problem
with disks filling up with clutter.  E.g.; interesting sources or notes
I find on the net go there, since if I don't get around to them within a
week, I probably won't get to them at all.

I like to be able to _really_ remove things, so I have not replaced rm
verbatim.  My shell function is called "erase", because that is what I
use when I'm working under DOS, where I'm afraid to get into the habit
of typing DEL; I'm afraid my fingers will type DEL sometime when I mean
to type DIR *.C, the two commands being so similar to my semi-autonomous
typing fingers.


-- 
Ken Hardy		uunet!racerx!ken		ken@racerx.UUCP