NFS bug: Sun client 'touch' zeroes mod time on Iris server

slevy at geom.umn.edu slevy at geom.umn.edu
Wed Apr 24 10:00:00 AEST 1991


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 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




More information about the Comp.sys.sun mailing list