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