Path: utzoo!attcan!uunet!aplcen!samsung!cs.utexas.edu!sun-barr!rutgers!pyrnj!hhb!istvan From: istvan@hhb.UUCP (Istvan Mohos) Newsgroups: comp.unix.wizards Subject: Re.: UNdeleting files Keywords: Super Block Message-ID: <571@hhb.UUCP> Date: 2 Aug 90 12:45:08 GMT Organization: HHB Systems, Mawah, NJ Lines: 117 peram@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@ndcheg.cheg.nd.edu (John Kellow @ Dep't of Chemical Eng., Univ. of Notre Dame) :(100 lines) More? [ynq] kellow@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@ndcheg.cheg.nd.edu -- Istvan Mohos ...uunet!pyrdc!pyrnj!hhb!istvan RACAL-REDAC/HHB 1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000 ======================================================================