Hard links to directories: why not?

[Leo de Wit]

In article <25668 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
|In article <837 at ehviea.ine.philips.nl> leo at ehviea.ine.philips.nl
|(Leo de Wit) writes:
    []
|                                                     When traversing trees
|>it just becomes a matter of following only the natural links (just like
|>skipping symbolic links the artificial links are skipped).
|
|Unfortunately, this does not quite work as desired:
|
|	% mkdir a b; ln b a/b
|(now a/b is the same as b, and a/b/.. is the same as ./..)
|	% unlink b		# (rmdir would complain)
|(now b is gone; only a/b names the inode that has a/b/.. the same as ./..)
|	% touch a/b/somefile
|	% find . -print

I guess it should say '.' where is says './..'; if a/b is the same as
b, a/b/.. is the same as b/.., which is '.' (unless you want '..' to
mean the ancestor - strip off the last path component -, in which case
a/b/.. is a).

|
|Since a/b/.. is not the `natural parent' a/b, find prints `a a/b'.  The
|file `somefile' has been `lost'.  You can still get to it---but if find
|were changed as proposed, it would no longer see it.

Well, I would say, if you play that nasty tricks, you get what you
deserve (just like you get what you deserve when you create circular
hard links).  Find, as it is, will also not find all files in a looping
directory structure, simply because it will start repeating itself at
some point.
When the check I proposed is added as an option to find, there is at
least a way to prevent looping if you want to.

    Leo.