Re.: UNdeleting files

[Istvan Mohos]

peram at cs.tamu.edu (Suresh B Peram) writes:
>   I have lost a whole directory containing
>   important information while running a shell-script...
>   I want to know where I can find the Super Block.

Well, you're not the first one this happened to.  Here is what
someone else had to say about it a while back (about a year ago):

:Subject: Re: Can you recover deleted files in Unix ?!?
:From: kellow at ndcheg.cheg.nd.edu (John Kellow @ Dep't of Chemical Eng., Univ. of Notre Dame)
:(100 lines) More? [ynq] kellow at ndcheg.cheg.nd.edu (John Kellow) writes:
:
:>I need some help.  Maybe this questions has been covered but I can't
:>remember seeing anything about it before.  Is there any way to recover
:>deleted files in System V.2 Unix?  I typed rm * when I thought I was
:>in the /tmp directory but guess where I was - that's right, my home
:>directory.  Unfortunately there were some important changes that
:>haven't been backed up.  I was the only person using the computer at
:>the time, and I immediately unmounted the file system.  My manual
:>entry for rm says something to the the effect that if a directory
:>entry was the last link count for a file then the file is destroyed -
:>does this mean data and everything?  Please tell me it isn't so.  I'll
:>be eagerly awaiting any replies.
:
:Well, in answer to my own question - I did recover the important data
:that I had deleted.  I guess the answer would be no, you can't
:"undelete" files in SYSV.2 Unix but you can recover individual blocks
:of data.  It took a few hours of trying to decipher the manuals and
:some trial and error but I think I've got it figured out and its not
:too complicated (someone correct me if I'm wrong).  The actual blocks
:of data are not removed, only the inode entry.  Since the inode entry
:contains all of the information as to what blocks belong to what file
:and in what order, you can't very well "undelete" the file but the
:data might still be there and you can piece it back together by hand.
:The names of the deleted files are not removed from the directory but
:the inode number is set to zero, so all that gives you is the list of
:which files were deleted.  The important information is the free list.
:The superblock contains a list of the 50 most recently freed blocks
:and the address of the next block in the list.  It seems that the last
:block freed will be the first block allocated, so you have to act
:fast!  Luckily I synched the disks and umounted the file system as
:soon as my mistake occured.  One more problem is that once the 50
:entries of free blocks in the superblock are filled, the free list
:will be copied into the next block to be freed, so that the free list
:space in the superblock can be used again.  In other words, for every
:50 blocks of space freed, 1 of those blocks will be used to contain
:the next block in the freelist.  That means that there's a very good
:chance that some of your data will be lost.  Now the good news,
:recovering the data is actually pretty simple (this all has to be done
:as the root user):
:
:	-Examine the Superblock of the file system with fsdb
:	 typing 512B.p0e will give something like this:
:
:0001000:     248       0   15760      32       0    1066       0    3584
:0001020:       0    3583       0    3615       0    3614       0    3613
:0001040:       0    3612       0    3611       0    3610       0    3609
:0001060:       0    3608       0    3607       0    3606       0    3605
:0001100:       0    3604       0    3603       0    3602       0    2496
:0001120:       0    3675       0    3684       0    3683       0    3682
:...
:
:	-248 is the # of blocks in the inode list,  15760 is the
:	 number of blocks in the file system,  32 is the number of
:	 entries in the free list and the next 50 numbers are the free
:	 blocks (but only the first 32 make up the current list)
:
:	-1066 is the first block in the free list and indicates the
:	 next block in the list, so if you want to recover more than
:	 the number of blocks in the current list(32) you would look
:	 in block 1066 and that would contain another free list with
:	 50 free blocks, with the first entry pointing to the next
:	 block in the list, etc.
:
:	-from what I understand, block 1066 was one of the blocks
:	 freed up but now it contains part of the free list so you
:	 can't recover that data
:
:	-write down the numbers of the blocks you want to recover and
:	 use bcopy to copy those blocks into files on another file system
:
:	-for example, to recover block 3584 type bcopy and answer the
:	 questions:
:	 bcopy
:	 TO: 3584 (this makes a file called 3584 in the current file system)
:	 OFFSET: 0
:	 FROM: /dev/fp003 (the name of the partion you're recovering from)
:	 OFFSET: 7168 (my version of bcopy goes by 512 byte blocks so
:	 I have to multiply 3584 by 2)
:	 COUNT: 2 (2 512 byte blocks or 1 1024 byte logical disk block)
:	 (it keeps asking FROM: so just press return twice to exit)
:
:	-Thats it, just use emacs or vi to look at the blocks and
:	 piece them back together, blocks belonging to the same file
:	 should appear consecutively in the free list but you don't
:	 know what order they should go in - thats not too difficult
:	 to figure out with text files but I guess binary files are
:	 another story (luckily I didn't need to recover any of those)
:	 
:Well, this explanation turned out longer than I thought but maybe it
:will help someone else in a similar situation.  I think most of this is
:standard System V.2 but some of it may be specific to my system.  I'd
:appreciate any comments anyone has.  Maybe there's a better way to do
:this or it seems to me that you could write a simple shell script or
:program to automate this procedure ( I hope I didn't go to all this
:trouble if there's already something that does this!).
:
:John Kellow
:kellow at ndcheg.cheg.nd.edu

-- 
        Istvan Mohos
        ...uunet!pyrdc!pyrnj!hhb!istvan
        RACAL-REDAC/HHB 1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000
======================================================================