Hard links to directories: why not?

Bob Goudreau goudreau at larrybud.rtp.dg.com
Wed Jul 25 06:00:22 AEST 1990


In article <839 at ehviea.ine.philips.nl>, leo at ehviea.ine.philips.nl (Leo
de Wit) writes:
> In article <1990Jul23.181554.17938 at dg-rtp.dg.com>
goudreau at larrybud.rtp.dg.com (Bob Goudreau) writes:
> |
> |In article <837 at ehviea.ine.philips.nl>, leo at 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 at dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA



More information about the Comp.unix.wizards mailing list