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

According to McKusick, it was done for compatability with lame POSIX
implementations which store symlinks in directory entries only and so
behave in the same broken way as the current BSD.

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

As one who has been ripping this "feature" out of my kernels since I
discovered its presence and not regretting it for an instant, I'd
argue that if we wanted lame POSIX compatibility we could implement a
lpfs (lame POSIX file system) or at least a mount option to ufs/ffs.

I _think_ I've submitted my patch via a pr - it was a long time ago.

--sjg