Ken - saw this post ...

#: > It just occurred to me, while reading a note about this, that it is
#: > _not possible_ to make symlinks "unowned" and still preserve sticky
#: > directory semantics
#: 
#: What do you mean "_not possible_"?  This is software we're talking
#: about, not physics.  IMHO sticky directories should retain the UID of
#: the actual creator, not assume you can fudge one up from the file's
#: inode.

...and your last one regarding keeping uid stuff in the directory, and
although I'm not one to do this sort of thing, the phrase

		BZZZT!  WRONG!

keeps popping into mind.

The directory structure is laid out as such because, relatively speaking,
it is streamlined.  Name and inode number are kept in the directory, and
stats are kept in the appropriate inode.

The problem is not the sticky directory -- that's worked *fine* until
someone tried to muck with the symbolic link.

I'll elaborate again, in case you missed it:

	Hard links are just creating a new directory entry which points
	to the same inode, and the linked-to source must exist _on the
	same physical device (filesystem)_.  In a sticky directory you get
	what you pay for.  The semantics of a hard link have been this
	way since (time_t) 0.

	Symlinks can point *anywhere*; the source need not exist (and,
	of course, the target must not exist, as with link()).  One can
	even link to directories and span filesystems.  This is a good thing!
	As such, a symlink was invented as a special file type which, due
	to the semantics of a (then-proposed) "soft" link, was a logical
	connection.  At least, to me, it's logical.  Since a symlink in
	no way affects its named object (until you open/read/write/chmod
	it), it stands to reason that it gets its own inode and set of
	information.  (Hard links immediately affect their linked-to
	object by updating the ctime and the link count.)


The idea of stuffing a symlink in as a "new kind of directory entry"
will serve only to muddy the current directory structure, and for things
which don't need stats and don't even necessarily need the object name
of the symlink, it will only add performance overhead.  Minimal, but still,
why do it?

Symlinks as of 4.3-Tahoe/Reno/Utah were not broken; why does POSIX insist
that we "fix" them?

#: 
#: ~Ken
#: 


					--*greywolf;