Re: Carrying Attributes too Far at Great Length

["Alexander G. M. Smith" <agmsmith@rogers.com>]

lrc1@st-andrews.ac.uk wrote on Fri, 10 Oct 2003 02:02:05 +0100:
> Should Cedric create photos/people/happy/good/ which links back to
> photos/people/happy/ , or should he create photos/people/good/happy/ ,
> which links back to photos/people/good/ ?)

Sure, you could have non-cyclic directory structures and just hard link
each individual file into all the relevant categories (directories).  But
sometimes I want to do a bunch of files, say a directory full of photos
from my vacation, and I want that to appear in directories identifying
the place and others identifying the people (.../cottage and
.../grandparents).  It isn't a full cycle, just multiple parents, but
supporting full cycles makes it easier to avoid implementation
problems with that (in case someone moves a parent directory inside
one of its children).  Or you could just disallow dangerous cycle
creating operations and avoid the full cycle implementation.

> However, there are certainly things in the current Unix implementation
> of hard linking that make multiple pathnames through hard links
> confusing and, yes, largely useless.

I want as much metadata about the file to be stored with the file (inode),
which means one unique file name.  One icon.  One set of attributes.  But
I also want some other things to be directory specific, such as the
desktop's icon position attributes.  I get around that by having an
Alias Generated Morphing Symbolic link (sort of a hybrid of a hard link,
a MacOS alias and a symbolic link).  The legacy OS sees it as a symbolic
link, which you can attach attributes to (such as icon position), yet it
also lets you deal with the file directly - the same difference as between
stat() and lstat(): http://www.FreeBSD.org/cgi/man.cgi?query=lstat

But it is not a real symbolic link since the target path string is
dynamically generated to identify the file's current true path.  If you
delete the other links to the file, the AGMS link "morphs" and becomes
the actual file (using a cunning sleight-of-hand inode swap under the hood).

> Given a full pathname, a file handle, or even an i-number, there must
> be a system call (or calls) to return all the hard-linked full pathnames
> of the given file, permissions allowing.  This removes the last advantage
> of using a symlink where you really want a hardlink [...]

With a list of parent links included in all inodes, you can do that.
It's just the doubly linked list vs single linked list concept - more
overhead, but we can afford it with modern hardware.

That's enough writing for now - I've recently finished my sabbatical and
started a full time game programming job.  Spare time for these interesting
discussions and code experiments has unfortunately vapourised, so I won't
be able to comment on everything said here.

- Alex