der Mouse responding to me wrote:

> > Why? Because the point of the POSIX standard is portable
> > applications, and I have a hard time seeing how that goal is advanced
> > by expansion of the symlink semantics beyond the point of industry
> > consensus.
> 
> Whereas _I_ have a hard time seeing how you are ever going to move
> forward if you stick to "industry consensus".

First there has to be a need to move forward, and I do not see symbolic
links as the crucial place where forward evolution is needed. Certainly
for NetBSD, there are likely more issues that could stand the spotlight
that has recently fried both symbolic links and run-levels.

The point I was trying to make is that application portability depends
on a consensus. And where such a consensus develops, whether we agree
with it or not, it is counter-productive to implement something that
is sufficiently different that a portability problem can develop.

> > If the industry segments represented in the POSIX working groups
> > could only get consensus with the current minimal specification of
> > symlink functionality, what purpose is served by insisting that
> > NetBSD must extend the semantics in a way that would encourage
> > non-portable application development?
> 
> I'm not insisting on anything.  I'm _suggesting_ things.  I've also
> implemented one of the suggestions.

I apologize if I attributed motives that were not your intention.

> You seem to think of NetBSD as a least-common-denominator system,
> something that does nothing but the minimum required by (in this case)
> POSIX.  This is pointless, crippling to nearly everyone trying to use
> it, and stifling to evolution.  I prefer to think of it as a testbed
> for trying new ideas.  Ones that work can be adopted, and if they
> really do work well and are useful will perhaps evolve into the
> "industry consensus" that seems so precious to you.  Ones that don't
> work can be discovered readily to not work and be dropped.

This leaps to a conclusion I fail to see in my original question above. 
"NetBSD as testbed" is entirely acceptable to me, and much of the reason
I personally use it. I do not see symbolic links as a new idea though.
They are an established technology for which honing a consensus from the
variations is appropriate. That means for me that I must be willing to
give up implementation features that are on the fringe of the concept
and do not materially affect the functionality.

> > I categorically reject any change that would let symlink permissions
> > override the access permissions of "hard" filesystem entities.  That
> > is clearly outside the bounds of existing art in this area.
> 
> And NetBSD is supposed to do nothing that is not existing art?  I quite
> disagree.

It is my fault for not being clear, the second sentence about existing art
is an observation, not a justification for the preceding position statement.

> > I do not claim the present design is perfect, only that it is
> > sufficient.
> 
> Perhaps it is.  If all you want is a "sufficient" system, you won't be
> interested in experimenting with my proposal.  But please don't try to
> stifle those of us who _do_ want to advance the state of the art.

Again I was unclear, I meant "sufficient" in the mathematical sense. And
I probably misunderstood your general motivations as well. I have no intention
of stifling any experimental work, I have never felt that to be a worthwhile
endeavor. The presence of this discussion in current-users is to me an
indication of a desire to make this the official NetBSD architecture.
I fear that such a change would walk away from a genuine attempt to come
to industry consensus on the conceptual basis of symbolic links. And that
in my opinion would be a mistake, and a disservice to the NetBSD community
of users.

> I really don't care enough about what POSIX does to bother.  I've
> thrown out some suggestions, is all; an attempt to explore possible
> meaning for some bits that were previously ignored.  POSIX is welcome
> to do whatever it likes with these suggestions.  I think it would be
> too early to mandate them; as far as I know only one system in the
> entire world is running with them in place.  Naturally, I'd prefer that
> it not mandate their absence, but if it does I'm certainly not going to
> let that stop me - the change is to a marginal extent incompatible with
> all other known current implementations of symlinks, but to my mind not
> critically so.

POSIX does not prevent extension, it merely channels it away from things
that need to be consistent for the purpose of application portability. If
you retain the symlink following for the syscalls that are not explicitly
excepted, then under the current draft language, there is nothing to prevent
you from adding interpretations to any of the other members of the stat
structure. To be able to modify those values would require new functions
in order to stay conforming. If you can live with that, then I think
all parties of interest can be accomodated.

/sjd