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