Date: Fri, 27 Dec 1996 16:33:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org, ben@narcissus.ml.org, owensc@enc.edu Subject: Re: multi-group file access techniques Message-ID: <199612272333.QAA25520@phaeton.artisoft.com> In-Reply-To: <199612261629.RAA08400@uriah.heep.sax.de> from "J Wunsch" at Dec 26, 96 05:29:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >From what I've gleaned from these postings, one of the biggest problems > > with them is the potential for creating loops in the file tree, which fsck > > is generally very unhappy about. If one is very careful not to create > > Our fsck were always very unhappy about additional hardlinks to > directories. > > > such loops _is_ it possible to safely employ hard-linked directories (and > > keep fsck happy) ? I can certainly see that they're very dangerous, but > > can they be used safely with FreeBSD? Anyone? > > Directory hardlinks are impossible in FreeBSD. They have been > discontinued quite some time ago. Directory hard links were disabled as far back as 1.1.5.1; I believe fsck can detect a cycle and ignore it (it used to be able to anyway) while issuing a warning message. Tar and most other programs aren't so lucky, and frequently their heads explode. There are a lot of good resons for *not* allowing directory har links; the best is that an ancestor pointer can be maintained in the inode at create or rename time (when the parent pointer is being fixed for the ".." entry) to allow trivial reverse traversal. This is useful for ACL and trustee-style permissions which may be reverse inherited, and which may be implemented as a stacking layer. In point of fact, it is possible to seperate the concept of an in core vnode reference from an in core inode reference so that hard links are similar in most ways to symlinks -- alias inodes, I think they are called in one implementation. Because the vnode reference and the data content reference is seperate, it's possible to determine from an open file the path used to open the file. This has a large number of useful consequences for security models which are so obvious that there is no need to go into them. Basically, hard directory link removal is a transition stage to changing the in core represenetation of directory data. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612272333.QAA25520>