In article <199507310434.AAA02478@pain.lcs.mit.edu>,
Chris G Demetriou  <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU> wrote:
> 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.

So, how about keeping the creator in the inode owner field for now.  Set
only at create time (I odn't think lchown is needed or desirable),
checked at delete time for sticky dirs.  Return it on lstat's too, for
tar's sake I guess (but anything that depends on it too heavily loses). 
If symlinks become dirent-only entities, just store the creator
information in the dirent as well.  Would this satisfy everyone?

> 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
>