🚀 go-pugleaf

In <2598@brchh104.bnr.ca> slevy@geom.umn.edu@uunet.uu.net (Stuart Levy) writes:

>Diagnosis:
>        SunOS utimes(), when called with a NULL array of struct timeval's,
>        emits an NFS setattr packet with 64-bit access-time (seconds &
>        microseconds) correctly set to the present moment;
>        the seconds portion of modification-time is also current,
>        but mod-time microseconds = 1000000 exactly.

>	Sun's NFS code actually does this intentionally, it turns out.
>	Smart servers are expected to take tv_usec=1000000 as a clue
>	that the time should be set to (the server's idea of?) the present,
>	while less smart ones would simply use the whole-second
>	part of the time.  SGI does neither, somehow.

The rocks should be thrown at Sun, because the bug is in their NFSSRC 4.0
and ONC/SRC 4.1 source releases to OEMs.  We've just fixed it in our
almost-shipping ConvexOS V9.1 release.  You're right that the client and
server have an agreement that 1,000,000 microseconds is a special 'magic'
flag in the protocol, but Sun didn't finish the thought; there's no other
code to pick up on that at the server end!  The code deliberately hammers
'0' into the mod time, as you've observed.  I think it'll do this on the
right release of Sun servers as well.  It looks like sloppy source control
at Sun.  SGI, like us, got burned because we ported the code a little too
fast :-)  Our fix was to comment out the code in the server that detected
the magic number entirely.

BTW, the best newsgroup to discuss this is comp.protocols.nfs - all 
followups should be to that forum.

Rob Thurlow, thurlow@convex.com