Hard links to directories: why not?

Leo de Wit leo at ehviea.ine.philips.nl
Tue Jul 24 21:16:17 AEST 1990


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.

|                             At least with symlinks, the user has an
|obvious and easy way to determine whether or not a directory entry
|will result in find hitting a dead-end:  if "ls -l" shows that the
|entry represents a symlink, then find won't traverse it.  But what
|does your scheme really buy that symlinks don't?

You make it sound as if I would advocate the use of hard links to
directories: well, not in the least. What I proposed was just a way to
determine whether a directory link is a true directory (in the sense
that it is consistent with '.' and '..') which optionally can be used
by tree traversal algorithms, like in find. By all means, use symlinks,
that's what I do too (not being superuser and such).

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.

    Leo.



More information about the Comp.unix.wizards mailing list