> there is a long-standing bug in NetBSD that I think now is ripe for
> at least a temporary fix until this can be done "right".

This is really a design bug, not a code bug.  Perhaps one could call it
an ill-thought-out feature rather than a bug.

> The problem is "who should be the owner of a symlink"?  Currently the
> owner is set to the owner of the directory where the symlink is
> created.

Not quite.  The idea is to present symlinks as objects which don't have
owners (which is currently not true; this is preparation for a day on
which it may be).  But _something_ has to go into the st_uid and st_gid
fields of the struct stat; the choice was to copy the ownership of the
containing directory.

> This causes problems with directories which have the sticky bit
> turned on (prominent example: /tmp), and opens up the ability for
> twarthing disk quota systems [...]

Right you are.  But it really is a design bug, not a code bug, since
the code is doing what it's intended to do.

> So, please, can a (temporary?) fix for this problem be implemented?

Would you care to suggest one?  So far, the only fix I've heard is to
go back to the old way of symlinks having owners and such same as
anything else in the filesystem.  A couple of people have, as you
noticed, submitted fixes that do that.  While I am not in a position to
speak authoritatively, I suspect that core is not doing this because
they want to be able to reimplement symlinks as a new kind of directory
entry, in which case they would not have inodes and truly would _not_
have owners...unless you count the owner of the enclosing directory,
which (surprise surprise :-) is the owner the current code gives them.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu