Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: comp.unix.wizards Subject: Re: stupidity in directory management? Message-ID: <27300012@ccvaxa> Date: Sat, 18-Jul-87 12:55:00 EDT Article-I.D.: ccvaxa.27300012 Posted: Sat Jul 18 12:55:00 1987 Date-Received: Sun, 19-Jul-87 20:55:23 EDT References: <603@nonvon.UUCP> Lines: 29 Nf-ID: #R:nonvon.UUCP:603:ccvaxa:27300012:000:1330 Nf-From: ccvaxa.UUCP!aglew Jul 18 11:55:00 1987 ...> Reusing directory slots for unlinked files. It's a bit off the subject, but one of the nicest things about working on an IBM PC was that you could "unrm" a file. When a file was removed, the first character of its name in the directory entry was zorched, but the rest of the information was untouched, so you could easily reconstruct it if you got there before its disk blocks were reused. Of course, you can do the same thing in UNIX if you know a file's inode (if the inode wasn't zeroed when blocks were freed), but you lose the connection between directory entry and inode when you unlink. And how many of us have an old "ls -i" output lying around. Some people alias rm to mv..., but that has obvious limitations (especially if you use rm -r a lot). What you could do would be NOT to zrch the inode in the directory entry, but to add a deleted bit. Deleted directory entries would be skipped on search, and reused as necessary, but would have the inode number. It might be nice to have an inode version number in the dir entry and the inode, that is incremented whenever a new inode is allocated. Compression would be a bit of a problem - you would want to leave a window between unlink and directory compression, so that careless people like me might have a chance to unrm. Maybe done by a daemon, or on demand.