unlink(2) - horror story

Curtis Jackson rcj at burl.UUCP
Wed Apr 30 22:38:12 AEST 1986


In article <422 at ukecc.UUCP> edward at ukecc.UUCP (Edward C. Bennett) writes:
>>In article <403 at ukecc.UUCP>, edward at ukecc.UUCP (Edward C. Bennett) writes:
>>>
>>>       But you can recover an unlinked file! I know, I've had to do it.
>>> You must unmount the file system and search the free list for your data.
>>> It's a PITA, but worth it if you lose something big.
>
>        When you unlink a file, the disk block addresses in the inode are
>zeroed, not the actual data blocks. Zeroing the inode is tantamount to
>'forgetting' where the data is actually stored. The 'forgotten' data
>blocks are added to the (top of the) free list to be used when adding data
>to the filesystem.

I know, and what a %#%@#@$ pain it is, too!  One night after working about
three 18-20 hour days in a row, I was writing a yacc parser for a
microassembler at about 2am.  When I got ready to throw it at yacc, I
managed to mistype a filename suffix and delete the thing.  Since it was
so late, there were only two people on the system I was using, and I had
superuser priveleges; I went into fsdb, into the superblock, found the free
list, and went screaming through it looking for my lost data.  Of course,
since freed blocks go at the HEAD of the free list, I only managed to find
about 150 lines of code -- and wouldn't you know they were 150 of the 200
lines of common code I had put in -- none of the original stuff.  I ended
up being so wired into the job I was doing that I was able to type in the
2000-line parser from memory *and it went through yacc and cc the first time*.

At that point I decided that:

a) I was dreaming
b) I had been working too hard for too long
c) There is a God

and promptly left and caught a flight back home from NJ for a long weekend.
Why the kernel designers didn't put newly-freed blocks at the END of the
freelist I'll never know.
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd allegra ]!burl!rcj
			...![ ihnp4 cbosgd akgua  watmath ]!clyde!rcj



More information about the Comp.sources.bugs mailing list