I see no value in prolonging the arg^H^H^Hdiscussion by quoting and
responding for another round. I did neglect to reference the Rationale
from the P1003.1a draft in my previous summary. I think that a couple
of paragraphs are useful to understand the context for the current
language of the draft.

>From the Rationale:

	Symbolic link:  Many implementations associate no attributes,
	including ownership with symbolic links. Security experts
	encouraged consideration for defining these attributes as
	optional. Consideration was given to changing utime() to allow
	modification of the times for a symbolic link, or as an
	alternative adding a lutime() interface.  Modifications to
	chown() were also considered: allow changing symbolic link
	ownership or alternatively adding lchown(). As a result of the
	problems encountered in defining attributes for symbolic links
	(and interfaces to access/modify those attributes) and since
	implementations exist that do not associate these attributes
	with symbolic links, only the file-type bits in the st_mode
	member and the st_size member of the stat structure are required
	to be applicable to symbolic links.

	Historical implementations were followed when determining which
	interfaces should apply to symbolic links. Interfaces that
	historically followed symbolic links include chmod(), link(),
	and utime(). Interfaces that historically do not follow symbolic
	links include chown(), lstat(), rename(), remove(), rmdir(), and
	unlink(). POSIX.1 deviates from historical practice only in the
	case of chown(). Because there is no requirement that there be
	an association of ownership with symbolic links, there was no
	point in requiring an interface to change ownership.  In
	addition, other implementations of symbolic links have modified
	chown to follow symbolic links.


One member of the ballot group has noted that readlink() is missing from
the list of functions that do not follow symbolic links. Other than that,
there was no objection to this description of historical precedent.

Bert Driehuis requested that I attempt to convince the POSIX working group
to loosen the requirement that chown() follow symlinks. That is exactly
the option I intended to pursue, though not without some misgivings about
how beneficial that approach might be. I worry that portability would
suffer, or would become unacceptably painful if chown() could either follow
or not follow symlinks. According to the rationale statement quoted above,
there are implementations supporting each of the alternatives. As noted by
the quoted text, lchown() and lutimes() functions may provide a cleaner
API for portability purposes. It is not what some of us (or maybe even the
whole NetBSD community) may think of as clean or historical, but it does
resolve an incompatibility between implementations.

I will make this offer to anyone with a particular interest in the POSIX
work on symbolic links. Since standards work is rather long term, and not
particularly speedy, I will lobby on behalf of those who are interested in
retaining conformance for their experimental symlink work.  Anyone wishing
to be kept informed about the results of this effort, please send me an
e-mail address (I will acknowledge receipt). If you have a suggestion for
improving the flexibility of the draft language, I will accept those as well.

/sjd