Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdahl!pyramid!uccba!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: stupidity in directory management?
Message-ID: <3670@ncoast.UUCP>
Date: Tue, 28-Jul-87 19:58:25 EDT
Article-I.D.: ncoast.3670
Posted: Tue Jul 28 19:58:25 1987
Date-Received: Sat, 1-Aug-87 09:21:57 EDT
References: <8414@brl-adm.ARPA> <1495@ihdev.ATT.COM> <746@sol.ARPA>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 19

As quoted from <746@sol.ARPA> by ken@rochester.arpa (Ken Yap):
+---------------
| What I did say was that if you are going to add this feature, then do
| it properly. Half baked hacks that scavenge the free list don't cut it.
+---------------

A correct *kernel* method should probably start with the file-generations
technique I posted a week ago.

However, what's wrong with rm(3) and unrm(3)?  Leave unlink() as is, and add
*functions* to implement undeleteable files.  These can then be used by most
programs while leaving unlink() as is.  Why force the kernel to do what user
code can -- isn't that the basis for UN*X having < 100 system calls where
many large operating systems have > 1000 (I'm thinking TOPS-20 specifically)?
-- 
 Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc
  {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal}!ncoast!allbery
ARPA: necntc!ncoast!allbery@harvard.harvard.edu  Fido: 157/502  MCI: BALLBERY
   <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>