Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!rice!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Hard links to directories: why not?
Message-ID: <1990Jul23.173709.26197@athena.mit.edu>
Date: 23 Jul 90 17:37:09 GMT
References: <5222@milton.u.washington.edu> <6940@eos.UUCP> <1990Jul19.115622.14015@mips2.cr.bull.com> <11070@alice.UUCP> <1990Jul22.175123.5323@athena.mit.edu> <837@ehviea.ine.philips.nl>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 49

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

  This will only hold true as long as ".." always points to the parent
directory of the first reference created.  This is true in most
implementations of Unix, but it does not *have* to be true, and in
addition, the POSIX standard doesn't require it.  Indeed, POSIX doesn't
even require that directory entries "." and ".." actually exist in the
filesystem; all it requires is that when a program accesses "." and
"..", it will get the current and parent directories respectively.  If
the operating system chooses to interpret "parent directory" as "the one
parent directory out of the several possible ones which was taken in
this particular case to get here," it is allowed to do that.  Indeed, I
would find that interpretation more useful than "the directory in which
the child directory was first created, no matter which parent you went
through to get to it this time."

  Relying on the way most filesystems work now is not a good idea,
especially when the standard says they don't have to work that way.

|> 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).

  I'm fairly certain that no such special code exists in find.  The
string ".." appears only once in the source code for find, and that's
when it'd doing a chdir(".."), so I don't think there's any code to
check the inode numbers of ...

  I'd test it, but whenever I try to create a hard link to a directory
as root, my workstation hangs or crashes.  I wonder why :-)

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710