> The idea of making symbolic links non-inode entities was not
> completely thought through (ownership problems) and doesn't
> buy very much savings in disk space.  For those reasons, we
> should just go back to the old way (make them inodes), at least
> until someone comes up with a design that doesn't break things.

they _are_ 'inode entities' right now -- it's just a question of
what's put in the inode, and what's displayed.


In my opinion (and i've had various arguments about this over the last
many months; i came to this opinion in the last week...  8-):
	file systems that have a need for the 'creator' information
	should keep it, and use it, but symlinks shouldn't have
	owners.

Apparently, POSIX is going to specify that most syscalls follow
symlinks.  (as i recall, the exceptions are readlink, lstat, unlink,
and rename.)

You can't change the ownership of symlinks, and can't change their
other attributes, etc., and the only thing that 'ownership' is used
for is figuring out if they can be removed, in a sticky directory in a
UFS.

You'll note that the behaviour of 'stickyness' apparently isn't going
to be specified...



The point of POSIX is to specify standard programming interfaces that
people can use to write 'portable' code.  How would _you_ handle
symlinks?

It seems to me that if one is going to display and use the ownership,
etc., then one must be able to set it.

One could argue that chown() (and similar functions) should be
reverted to not follow symlinks...  So, then, how does one change the
ownership (or whatever) of the things pointed to by the links?

Or does one introduce an 'lchown()', etc., set of functions, and say
"they may fail if symbolic links do not support the attribute..."?


Whether or not you think they're 'well designed', there _already_
exist file systems which on POSIX-conformant systems which support
symlinks as directory entries, and any solution that's picked must
sanely address the problems that symlinks create.

It's worth noting that CSRG changed (slightly) the way that symlinks
behave, in Lite2.  In Lite2, (1) the inode is reported by lstat()
(though, depending on this feature isn't POSIX-safe), and
(2) _anybody_ can remove symlinks in sticky directories.  I think
there was another change, but i forget what it is...  I strongly
object to the latter.  However, i don't like restricting removal to
the user who created the link if you can't easily tell who that was...
but there are reasons (outlined above) why it's not clear if it's
appropriate to report the 'owner'...



chris