Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!brl-adm!adm!bzs@bu-cs.bu.EDU From: bzs@bu-cs.bu.EDU (Barry Shein) Newsgroups: comp.unix.wizards Subject: stupidity in directory management? Message-ID: <8408@brl-adm.ARPA> Date: Wed, 22-Jul-87 14:59:02 EDT Article-I.D.: brl-adm.8408 Posted: Wed Jul 22 14:59:02 1987 Date-Received: Fri, 24-Jul-87 05:49:35 EDT Sender: news@brl-adm.ARPA Lines: 41 Note that TWENEX had a nice undelete built into the O/S and had solutions to a number of the policy problems (eg. when to *really* delete and free file space) that are at least worth reviewing before attempting a design. I believe file space was reclaimed under three conditions: The user issuing an explicit EXPUNGE (was that it?) command, logging out of that directory or the Grim File Reaper running (a daemon, usually either touched off manually by an operator or based on something like only 10% disk free, with some broadcast warnings, like a shutdown.) The problem in Unix with this is not how to represent an undelete-able file (sure, a bit in the directory entry sounds plausible, or whatever) but how to sweep. You can't put the delete bit into the inode because it should probably only be on a per link (even when link count == 1) basis. If it's in the directory entries then you have to descend and sweep the entire tree, non-trivial on larger machines with gigabytes of disk. My experience with TWENEX was that operator or daemon initiated file purges were initiated several times per day on some systems (several times per minute on OZ some nights :-) You just kinda fall into these bad habits real quick. What I'm saying is it might take some low-level re-design, like allocating directory blocks into known contiguous places on the disk so they can be swept by a low-level utility quickly, similar to the inode area but, hopefully, dynamically extendable. This might be useful for other things also, I haven't thought much about it. It also will add some hair to the file system call interface which needs to be anticipated, like a flag to unlink() indicating whether to really delete or not and probably some thought about what to do about trying to name (rename(), creat(), mkdir()) a file the same as a currently undelete-able file, TWENEX used generation numbers which is a whole 'nother design problem that perhaps should be simultaneously broached (eg. foo.bar.1, foo.bar.2, the numbers automatically generated, opens not specifying a number [open("foo.bar",0)] get the highest un-undeleted version, etc.) -Barry Shein, Boston University