Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!rti!dg-rtp!larrybud.rtp.dg.com!goudreau From: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Newsgroups: comp.unix.wizards Subject: Re: Hard links to directories: why not? Message-ID: <1990Jul24.200022.2265@dg-rtp.dg.com> Date: 24 Jul 90 20:00:22 GMT References: <5222@milton.u.washington.edu> <6940@eos.UUCP> <1990Jul19.115622.14015@mips2.cr.bull.com> <11070@alice.UUCP> <1990Jul22.175123.5323@athena.mit.edu> <837@ehviea.ine.philips.nl> <1990Jul23.181554.17938@dg-rtp.dg.com> <839@ehviea.ine.philips.nl> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Organization: Data General Corporation, Research Triangle Park, NC Lines: 56 In article <839@ehviea.ine.philips.nl>, leo@ehviea.ine.philips.nl (Leo de Wit) writes: > In article <1990Jul23.181554.17938@dg-rtp.dg.com> goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes: > | > |In article <837@ehviea.ine.philips.nl>, leo@ehviea.ine.philips.nl (Leo > |de Wit) writes: > |> > [] > |> No need for that if find only - recursively - follows those > |> subdirectories 'sub' for which the inode of 'sub/..' is the same as > |> that of '.' ... > | > |... thus defeating the purpose of find, since the user doesn't get > |what he expected to get (namely, the entire directory tree descending > |from his specified target). > > But that WILL be exactly what he gets! Rejecting artificial links > because those can let you traverse a structure that is anything but a > tree (the simple case can indeed be an artificial link pointing to > another tree, but more complicated ones could point to a tree that > shares some part with the current tree, or - worse - contains the > current tree). I cannot imagine the user wants looping, or trees > traversed twice. Precisely -- that's why on most systems that support symbolic links, find doesn't traverse symlinks (at least, not by default). My point was that "artificial" hard links are just a poor imitation of symbolic links. You can't span file system boundaries with them, and they aren't as easy to detect as real symlinks (see below). If you prohibit non-superusers from unlinking them, then you're stuck with the unlovely situation of users being unable to delete links they've created, even though they have write access in the affected directory. If you lift this prohibition, then you can easily end up with directories whose ".." entry points nowhere (or worse yet, points to what used to be the parent inode, but has now been recycled into something completely different). > If a user has to "ls -l" to check whether a directory entry is a > symlink and as such would result in find hitting a dead-end, this > strikes me as a non-obvious way, since being consequent he has to do it > for the complete directory structure. But your "artificial" hard-links suffer from the same problem, only more so! In order to distinguish the wolves (artificial hard links) from the sheep (real hard links), it's necessary to compare the inode number of "." and "wolf/..". This is far more of a pain in the ass than just figuring out if "wolf" is a symlink or not. ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA