NFS unreliable about getting/setting time fields in inodes

[Gary Gordon]

I have noticed that doing a stat() (or fstat()) call on a file residing on
an NFS-mounted file system yields stale times for the st_atime, st_mtime,
and st_ctime fields in a stat structure.  In addition, doing a read() on
the same file doesn't seem to update (at least right away) the access time
in the inode on the machine where the file actually lives.

I am running on a Sun 3/50 workstation, running SunOS 3.5, and this is
connected to a Harris HCX-9, running HCX/UX 3.0.  If I have a non-zero length
file named "foo" on the Harris, and run the following program on the Sun, I
get the behavior noted above:

#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

extern long lseek();

main()
{
	int fd;
	struct stat s;
	char ch;

	if ((fd = open("foo", O_RDONLY)) < 0) {
		perror("open");
		exit(1);
	}
	for (;;) {
		if (fstat(fd, &s) < 0)
			perror("fstat");
		(void) fprintf(stderr,
		    "access: %ld, modify: %ld, change: %ld\n",
		    s.st_atime, s.st_mtime, s.st_ctime);
		sleep(3);
		if (lseek(fd, 0L, 0) < 0)
			perror("lseek");
		if (read(fd, &ch, 1) < 1)
			perror("read");
	}
}

Running the program shows that the access time is not updated immediately
after the read(), and in fact suddenly just gets updated over a minute
later.  In addition, running the same program simultaneously on the Harris,
without the lseek() and read() calls, shows the access time unchanged on the
Harris; i.e. the read() across NFS from Sun did not cause the inode on the
Harris to be updated.

I have looked at the NFS protocol spec, and don't see this topic addressed
anywhere.  If anyone has some insight as to what exactly NFS is doing,
regarding buffering of some sort, or whatever, I'd appreciate hearing about it.

					Thanks,
					GG

-- 
Gary Gordon                         Visix Software, Inc.
...!uunet!visix!gary                P.O. Box 12547  Arlington, VA 22209
visix!gary at uunet.uu.net             703/841-5843