Hard links to directories: why not?

[Chris Torek]

In article <837 at ehviea.ine.philips.nl> leo at ehviea.ine.philips.nl
(Leo de Wit) writes:
>... 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).

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

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.

The trick here is that symlinks are truly special.  In the symlink case:

	% mkdir a b; ln -s ../b a/b
(must use `../b' since symlinks are interpreted relative to their place
in the tree)
	% rmdir b
	% touch a/b/somefile
	touch: a/b/somefile: No such file or directory
	% 

What is going on: a hard link always refers to some particular inode
(the inode is the `real' existence of a file; a directory entry or path
name is simply a way of naming the inode), and that inode hangs around
until there are no references to it.  A symlink, on the other hand,
simply contains a string that, when the symlink is used as a part of
a path name, is spliced in `in place' of the symlink itself.  (Certain
operations, e.g., lstat, do not splice in the symlink when it is the last
component of a pathname.)  Since the symlink does not hold a reference
to the *real* file (directory), when the name `b' is removed the referece
count goes to zero and the file actually goes away.  The symlink is then
`orphaned', whereas the hard link `a/b' was simply left around with an
`invalid' `..'.  If a new name `b' is created the symlink then resolves
to the new b, whereas the hard link a/b would not.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris