Lon Willett writes:

[ A whole bunch of reasons why the new symlinks would not be detrimental
  to a system, and then...]
[SOMEONE says:]

#:     > Sure, I can hard link to a file I don't own, but if *I* hard link
#:     > to a file I *do* own I'd want to be able to remove it.

You can do this now.  As long as you own the file to which you are linking
you can delete the link from a sticky directory.

[But then Lon wrote]:

#: The real reason to use the POSIX semantics is to avoid having to make
#: tar/cpio/every-other-archiver understand symlink ownership; and to avoid
#: having to implement "lchown" and l-every-other-inode-manipulating-syscall,
#: and then having to make NFS deal with them.  And then you'll still have
#: problems with older NFS servers that don't give you "lchown" or don't
#: support it in their underlying FS.

The real reason to use the POSIX semantics is to avoid being labeled as
a non-POSIX-compliant system, and for no other reason.

The POSIX semantics for this don't make sense, and your comment about
tar/cpio/every-other-archiver doesn't really apply here, considering that
tar/cpio/every-other-archiver has been dealing with this very problem for
years without a hitch.

Since times on a symlink are not necessary and don't change (unless you 
implement them as per der Mouse's suggestion), lutimes() becomes unnecessary.
Since modes on a symlink are not necessary and don't change (unless as
previously mentioned), lchmod() becomes unnecessary.  The only confusion that 
I have is that chmod() affects the target while chown() affects the link,
but it's been this way for ages, and if we change it so that lchown() affects
the link, this will break existing code.

Considering that lstat/stat had me confused for the LONGEST time (I thought
that lstat was the one that gave you stats on what the link pointed to, even
after reading the manual page.  Semantics, I guess.) I wonder if there would
be even an epsilon of sense in making lchown() actually follow the link.

An alternative would be to have chown()/chmod()/utimes() (as necessary; 
currently the only problem seems to be with chown()) have an extra argument
at the end:  u_int nofollow, which, if set, would (*func)() the link in-
stead of the object.  Of course, if chmod() were to become important,
the semantics would be reversed since chmod() currently affects the target,
while chown() currently affects the link (have I said that enough yet?
"Hello, department of redundancy department...")...

#: 
#: Again, perhaps I've missed something in this thread, but I don't see
#: what having symlink ownership buys you that is worth the extra
#: complexity that must be added to every program that attempts to grok the
#: filesystem.  The only real reason I've heard is disk quotas. But since
#: giving someone write access to a file or directory you own (sticky-bit
#: or not) automatically lets them do some things that count against your
#: quota and not theirs, I don't see this as significant.  Assuming
#: non-malicious behaviour, how many symlinks are created in directories
#: other by its owner?  Not many, I'll bet.  And, as I've mentioned,
#: malicious behaviour is possible anyway, regardless of the way symlinks
#: are handled.

Well, not exactly.  If symlinks take up disk blocks, you won't be able to
create *nearly* as many as if they just took up dirent space.

Someone else brought up a good point -- overhead of a new dirent type
would be less than minimal, since what if you have a directory with
lots of almost-maximal-length symlinks in there?  If you want some entry
after those symlinks, you're always seeking past (n) symlink entries
plus their names (at 1000 bytes each).  That could be a (everyone chime
in here) PERFORMANCE HIT.  (Very nice, thanks).

#: 
#: To me, the KISS principle seems to dictate that the POSIX semantics are
#: a good thing.  And yes, the sticky bit hack needs a little more work,
#: but I think that it does anyway (i.e. I don't think you should be
#: allowed to hard link files you don't own into a sticky-bit accessed
#: directory).

POSIX is only attempting to force us to convolute what is already simple.
What we have works -- a symlink is a file type, not a dirent type.
Let's just leave it alone.

					--*greywolf;

#: 
#: --Lon Willett
#:   willett@math.utah.edu
#: