NFS bug: Sun 'touch' zeroes mod-time on SGI server

[Stuart Levy]

[I've sent this a couple times to 'comp.sys.sun,comp.sys.sgi' but never
saw it on the latter, so I'm posting it here alone.]

There seems to be an incompatibility between the SunOS 4.* NFS client
and SGI 3.3 server implementations.  I'd have called it a Sun bug, but
(if you take Sun's implementation as authoritative) it appears it's really
an obscure protocol "feature" which SGI mishandles.

One of our users, trying to touch files to force make to recompile them,
found it ineffective.

Environment:
        SunOS 4.x {4.0.3, 4.1, 4.1.1 at least} NFS client
        SGI {3.3.1 at least} NFS server

Symptom:
        ``/usr/bin/touch file'' (or /usr/5bin/touch file) on the Sun,
        when the file already exists, lives on the SGI NFS server,
        and is owned by the user doing the touch, sets the file's
        modification time to *zero*:

    % /usr/bin/touch /usr8/rats; ls -l /usr8/rats
    -rw-rw-rw-  1 slevy           0 Dec 31  1969 /usr8/rats

        On the other hand, if "file" is local or NFS-mounted from a Sun server,
        touch works as expected -- both access and modification times are
        updated.  Ditto if ``touch'' is run on an SGI client.

        Meanwhile, Sun /usr/bin/touch or /usr/5bin/touch with explicit
        arguments (-m, etc.) does the Right Thing.

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.

This note is mostly a bug report -- if you-all have been finding file mod
times set to 1969, this is probably why -- but if anyone knows of a workaround
I'd be glad to hear of it.

    Stuart Levy, Geometry Group, University of Minnesota
    slevy at geom.umn.edu, (612) 624-1867