Hard links to directories: why not?

[Leo de Wit]

In article <1990Jul22.175123.5323 at athena.mit.edu> jik at pit-manager.mit.edu (Jonathan I. Kamens) writes:
|
|In article <11070 at alice.UUCP> andrew at alice.UUCP (Andrew Hume) writes:
|
|   on the other hand, links to files already do that to some extent.
|   and symbolic links do it completely as you can symlink to directories.
|   allowing hard links to dirs makes the problem no worse, really.
|
|Actually, it makes it much worse.  Symbolic links can be quite easily
|detected by any program that is concerned about circular filesystem
|structures, since a symbolic link has a different file type from the
|file to which it points.
|
|However, there is no way for a program to easily detect, without
|keeping lots of internal state showing which inodes have already been
|visited, when it is reading a hard link.  Hard links are no different
|from normal files.

As a matter of fact, there is. Normal files are just hard links, like
you said, but a difference between a 'real directory' and an 'alias
formed by a hard link to a directory' is that the .. of the former is
the natural parent (the directory you get by stripping off the last
path component), while the .. of the latter is not. When traversing trees
it just becomes a matter of following only the natural links (just like
skipping symbolic links the artificial links are skipped).

|
|For example, "find" has no trouble at all dealing with symbolic links,
|but it can quite easily get into a looping state if it encounters a
|hard-linked directory pointing higher up in the directory structure.

No need for that if find only - recursively - follows those
subdirectories 'sub' for which the inode of 'sub/..' is the same as
that of '.' (I wouldn't be surprised if there was already something of
the same tenor in the source of find).

    Leo.