gary@visix.UUCP (Gary Gordon) (05/15/89)
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@uunet.uu.net 703/841-5843