Finding symlink information in MAC Framework

[perryh at pluto.rain.com]

jan.grant at bristol.ac.uk wrote:

> On Wed, 27 Jul 2011, perryh at pluto.rain.com wrote:
...
> One additional thing that symlinks manage to do is to refer to
> directories as well as files

Yes; I left that aspect out by way of simplification since it did
not seem pertinent to the OP's situation.

> hard links to directories spawn problems such as requiring garbage
> collection and smarter filesystem descent algorithms, which is
> another reason they're typically prohibited except in the case
> where they're created by "mkdir".

or by "mv", when moving a directory within the same physical
filesystem.

The two biggest problems I'm aware of are:

* They create the possibility that the filesystem is no longer a
  tree but a more general directed graph which may even be cyclic.
  The possibility of a cyclic graph would indeed require handling
  in utilities such as find(1) and "ls -R", but the only case I've
  thought of that would need garbage collection -- as opposed to
  some minor extension of the current reference-counting scheme
  -- would be detection of cycles that have become disconnected
  (unreachable from either the root or any currently-open
  directory).

  However, I think prohibition of hard-links to directories is not
  sufficient to prevent the creation of isolated cycles.  Consider:

  $ mkdir -p /tmp/a/b/c/d/e/f/g
  $ cd /tmp/a/b/c/d/e
  $ mv /tmp/a/b f/g

  Unless either mv or the kernel goes to some trouble to detect the
  subterfuge, this will create an isolated cycle f/g/b/c/d/e/f/...

* Where should my .. entry point, if links to me (other than my .
  entry and my subdirectories' .. entries) appear in more than one
  directory?

> FWIW one of the early unix systems I was exposed to permitted the
> creation of hard links by arbitrary users.

Just _one_?  I've never heard of any that did _not_ permit that!
(AFAIK Posix requires it.)