Xref: utzoo comp.unix.questions:6709 comp.unix.wizards:8046
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Recovery ofremoved files
Message-ID: <1079@mcgill-vision.UUCP>
Date: 26 Apr 88 07:58:25 GMT
References: <367@axis.fr> <54@lakart.UUCP>
Organization: McGill University, Montreal
Lines: 36

In article <54@lakart.UUCP>, dg@lakart.UUCP (David Goodenough) writes:
> From article <367@axis.fr>, by inra@axis.fr (Inst. Natl. Rech. Agronomique):

>> After rm command is it possible to recover removed files

> Believe it or not, but way back in the dim and distant past, a guru I
> knew at university had an unrm program (from what I could gather, it
> knew the nature of the freeblock list, and it looked at where the
> returned blocks were put, and then wrote their contents to a
> different file structure.)

Much like what various programs can do under MS-DOS.  This is one
advantage of a simple ("primitive") filesystem - you can pull tricks
like this.

> Admittedly this was done under UNIX V6 from bell labs - whether the
> idea is portable to BSD or System 5, I have no idea.

I looked at doing this for 4.3.  Normally, people will dismiss the idea
because 4.3 doesn't keep a freelist in the usual sense - it's more like
bitmaps of free blocks.  But I considered leaving the block pointers
around, just zapping the size field of the inode, so if you caught it
before the blocks got reused (always a requirement), you could see the
pointers still there.  However, it looks as though it isn't going to
work.  When a file is extended, it is done by writing past the end.  If
there is a hole, the block addresses there are left untouched as far as
I can tell, which means they better be zero, or the file hasn't
acquired holes; it's suddenly acquired blocks that nobody ever expected
it to have.  Bad news.  This might be fixable, but would require a fair
piece of kernel work (wherever the size is grown, it must be careful to
clear block addresses as appropriate).

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu