Date: Fri, 27 Dec 1996 00:22:56 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: owensc@enc.edu (Charles Owens) Cc: julian@whistle.com, j@uriah.heep.sax.de, freebsd-hackers@freebsd.org, ben@narcissus.ml.org Subject: Re: multi-group file access techniques / directory hardlinks Message-ID: <199612262222.AAA01564@eac.iafrica.com> In-Reply-To: <Pine.FBS.3.93.961226155820.24466G-100000@dingo.its.enc.edu> from Charles Owens at "Dec 26, 96 04:06:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612262222.AAA01564>