mark@spider.co.uk (Mark Valentine) (06/13/91)
After spending a few hours typing in a fairly lengthy shell script, my brain decided I'd better rm it immediately (you know the evil way these minds work). I happened to be using rlogin from within Oliver Laumann's "screen" utility at the time, so I su'd, typed "less /dev/disk", used "/" to search for a few remembered variable names, and checked on its progress every now and then. When I saw a block on the free list I recognised, I used the screen-dump key to save it to local host's disk. By the end of the afternoon (after just two or three passes) I was able to do a simple cat and edit and found myself only a few bytes short. It's nice to be able to take a leisurely approach to these things now and then! Mark. -- Mark Valentine, Spider Systems <mark@spider.co.uk> /\oo/\ "I'll be mellow when I'm DEAD."
dylan@ibmpcug.co.uk (Matthew Farwell) (06/13/91)
In article <1991Jun12.231044.14542@spider.co.uk> mark@spider.co.uk (Mark Valentine) writes: >After spending a few hours typing in a fairly lengthy shell script, my brain >decided I'd better rm it immediately (you know the evil way these minds work). > >I happened to be using rlogin from within Oliver Laumann's "screen" utility >at the time, so I su'd, typed "less /dev/disk", used "/" to search for a few >remembered variable names, and checked on its progress every now and then. >When I saw a block on the free list I recognised, I used the screen-dump key >to save it to local host's disk. By the end of the afternoon (after just two >or three passes) I was able to do a simple cat and edit and found myself only >a few bytes short. I did this sort of thing too. I was using a package under DOS (I'll forget the name to protect the guilty), that had the concept of volumes on the disk. Each volume had a load of files underneath that volume (sort of like a directory but more primitive). Filenames are specified as VOL:fredleg. Anyway, one day I copied a file to a new volume without specifying the filename (just the volume name). You'd think that it'd just use the original filename wouldn't you? (I mean, even DOS does that). Wrong. It copied the file directly onto the volume. There was now a file called VOL: in my directory. Worse than that, everything in that volume (all the work i'd done in the past 4 hours) was gone. These files weren't in DOS format, so running Norton or anything like that wouldn't have worked. So, I toddled over to my Xenix box and copied the raw disk to a file in /tmp, ie cp /dev/fd196ds9 /tmp/disk, then emacs'd the file. I got it into a state where I could vi it, and convert it back to DOS format (the package could read DOS disks). It took me about 10 minutes. Dylan. -- Matthew J Farwell: dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan But you're wrong Steve. You see, its only solitaire.
clarsen@lbl.gov (Case Larsen) (06/14/91)
Late last year, someone "accidentally" typed 'rm -rf /usr/users' on one of my friend's NeXT machines (Mach/Unix with the BSD 4.3 filesystem) as root. Yes, I think they are still working there. Of course, a lot of people were angry. "No big problem", you say, "just restore from backup tape." But my friend wasn't keeping backups because of some silly reason--media cost, most likely. At this point, we 'dd' and compress all 330 megabytes of /dev/rsd0a to a file for later perusal. (Eventually, we'll have to spread the 330 megs across multiple disks because there just wasn't that much free space on any one disk.) Another friend and I try a feeble attempt to try and recover inode information from the disk. As I remember, the directory inodes of /usr/users were still intact, but the inode pointers to the subdirectories had been zeroed out. For attempt #2, we get a version of 'fsdb', pull out the inode manipulation code and write a pattern scanner for the disk image. The first thing we do map out all the blocks of the disk that contain something "textual" and "important". "Textual" and "important" rules out blocks containing what looks like system logs, mail messages, binary data, etc. At this point, I think there were about 50 megabytes left. We then took the map files for the text blocks and had the scanner search through them for certain files that the professors think they lost. All that was needed was a string of text, such as the title of the paper, or the professor's name. As soon as a block containing the string was found, the consecutive blocks before and after the block could be dumped to a file. In almost all the cases, the blocks of the original file were both consecutive and in order. The time taken from being given the search text, to dumping a copy of the text file was about 30 minutes. Most of this was spent searching through the 50 megs of text blocks. The saving grace of the BSD filesystem was that for small files (less than 8K), an entire 8K block was allocated instead of a scattered bunch of smaller 1K fragments. I'm not sure what happens with files larger than 8K, but at some point, they start to get staggered to improve transfer time and striped across the cylinder groups. We never tried to recover files that large, so it wasn't an issue. -- Case Larsen clarsen@lbl.gov uunet!ucbvax!lbl-csam!clarsen Voice: (415) 486-5601 Fax: 486-5548 Lawrence Berkeley Laboratory, One Cyclotron Road -- MS 50F, Berkeley CA 94720