> ls is welcome to do whatever it wants with the st_mtime field.  POSIX
> just doesn't promise that there's useful information there for
> symlinks.  

s/POSIX/The POSIX.1a draft/

Referring to a draft POSIX standard as POSIX confuses the issue.  I
have copies of early POSIX.2 drafts, and there are places where they
are significantly different than the standard that was finally adopted.

> One would hope that systems that do in fact maintain mtimes
> for symlinks would return it; on systems that don't, of course, you
> can't get it no matter how you try.

Someone posted the POSIX draft's rationale for symlink stuff, and I
see nothing that requires our current (IMHO) lame behavior.  Just
because the POSIX comittee is accomidating systems without inode stuff
in their symlinks, doesn't been we should rush to match those least
common denominator systems. 

I'd like to know what the draft standard really says about symlink
foo.  In the past, the POSIX comittee have been rather conservative
about not breaking traditional behavior and have left things
unspecified when faced with established conflicting behaviors.  I
find it unlikely that they have given up this.

I also wish that NetBSD had a representitive on the POSIX comittee,
but it's very unlikely that we'd be able to come up with the money
necessary.  I don't know if there is way to participate as a non-
voting, non-attending person --- just getting and commenting on the
drafts.  That would probably be reasonably affordable.

And I agree with the change that chown should follow symlinks.
Consistancy with other syscalls is a good thing.  I just think that
NetBSD should continue to maintain uid/gid/*time too.  even if there
is no API to change them (although I see no harm in a SVR4 like
lchown() syscall).

> (ls on the latter type of system probably shouldn't print any time
> for symlinks, but that's a quality-of-implementation issue.)

I think ls would have to print something, othewise scripts that expect
specific fields in a particular column would break.

	--jtc