From owner-freebsd-hackers Thu Dec 26 14:28:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA12845 for hackers-outgoing; Thu, 26 Dec 1996 14:28:11 -0800 (PST) Received: from eac.iafrica.com (196-7-192-110.iafrica.com [196.7.192.110]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA12840 for ; Thu, 26 Dec 1996 14:28:05 -0800 (PST) Received: (from rnordier@localhost) by eac.iafrica.com (8.7.6/8.6.12) id AAA01564; Fri, 27 Dec 1996 00:22:57 +0200 (SAT) From: Robert Nordier Message-Id: <199612262222.AAA01564@eac.iafrica.com> Subject: Re: multi-group file access techniques / directory hardlinks In-Reply-To: from Charles Owens at "Dec 26, 96 04:06:16 pm" To: owensc@enc.edu (Charles Owens) Date: Fri, 27 Dec 1996 00:22:56 +0200 (SAT) Cc: julian@whistle.com, j@uriah.heep.sax.de, freebsd-hackers@freebsd.org, ben@narcissus.ml.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Sorry about the previous message, which got away before it was ready.] Charles Owens wrote: > On Thu, 26 Dec 1996, Julian Elischer wrote: > > > Charles Owens wrote: > > > > > 1. The file system does in fact support directory hardlinks. (This is > > > true at least to some extent, since the '.' and '..' entries are, > > > in fact, directory hardlinks.) > > > > see below. [ ... ] > > > > > > Am I correct here? Would someone in the know provide clarification? > > > > the KERNEL now disallows the 'link' operation on directories. > > Ok... that's very clear, but a bit terse. :-) What I'm digging for above > is an expression of the rationale for this disabling (_not_ that I > disagree). I certainly can see that directory hard linking should be > disabled as long as support in the basic tools (rm, rmdir, fsck) is > incomplete (otherwise it's a major head-ache for the user). ...But if the > tool support was made complete I'm not so sure that this kernal disabling > is the way to go. Perhaps there could be a options flag in the kernal > config file to force directory linking to be allowed for those who need > it. One fundamental limitation is the deadlock detection scheme in ufs_lookup, which can't handle hard links which point towards the root of the file tree. (`..' is treated as a special case.) Generalized detection of backward links would require different, and more complex, handling of LOCKPARENT cases. -- Robert Nordier