Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ptsfa!ihnp4!ihdev!pdg
From: pdg@ihdev.ATT.COM (Joe Isuzu)
Newsgroups: comp.unix.wizards
Subject: Re: stupidity in directory management?
Message-ID: <1495@ihdev.ATT.COM>
Date: Thu, 23-Jul-87 10:57:35 EDT
Article-I.D.: ihdev.1495
Posted: Thu Jul 23 10:57:35 1987
Date-Received: Sat, 25-Jul-87 10:44:40 EDT
References: <8414@brl-adm.ARPA>
Reply-To: pdg@ihdev.UUCP (Joe Isuzu)
Organization: American Nasal Amputation Centre
Lines: 51


It seems that the general concensus is to start adding stuff to the
kernal to improve directory management (deleted, invisible files as in
TOPS-20).  Many users simply have aliases set up for rm to actually
move the files to a .deleted directory or some other such scheme ehere
they can be unrm'd, expunged or cleaned up by an operator driven
daemon, just like in TWENEX.  This was the general scheme at one
institution I attended, which was primarily TOPS-20 based, but was
switching to smaller UNIX systems.  The advantages here were that
naive users had this ability more or less transparently, and system
utilities worked as they always did with no modifications.  The
disadvantage was that system utilities worked as they always did :-).
Try explaining to a new UNIX user, "well the first time it was removed
with rm which doesn't really remove it, although the *real* rm *does*
really remove it, you used rmdir which is a different dog
altogether.". It seems though that this ability (to be able to
undelete a file) needs to be *very* closely related with generation
numbers, so you dont rm a file, try to create a new version and get
told 'file already exists' - assuming the 'removed' files are kept in
the existing directory.
I can see it now "But I just removed it
(whiney voice)".  I'd be interested in hearing how the GNU folks are
resolving this issue.  I think if you really were trying to put this
in the kernal properly, the file system switch would be the only way
to go (so existing applications which do much file creation/deletion
would not be affected by the additional overhead/disk usage).  Between
the FSS and getdents it would not seem to difficult to set up all of
this more or less transparently (open opens the most recent version
for read, increments the gen count and opens a new file for write,
getdents gives only one version, and have ioctls on directories to do
expunge, and an alternate way of opening a directory (read another
name - like 'dirname@') to get all entries.  Anyway, just some random
thoughts before this mornings first cafeine has hit my brain.

Now, invisible files (a la TWENEX).  Did anybody really use these?  I
always had a PCL-EXEC (wasn't that an *incredible* exec - except for
the parse until get a syntax error, say 'errror on line x' and bomb
compilation scheme) function to have dir get invisible files too.  I
really don't think these were too useful, but for the same affect on
UNIX, 

function make-invis {
	mv $1 .$1
}

(half a :-})  (gosh GNUmacs really should recognize smiley faces and
not give you `mismatched parenthesis' errors)
-- 

Paul Guthrie				"Another day, another Jaguar"
ihnp4!ihdev!pdg				    -- Pat Sajak