Because the NFS architecture differs in some minor ways from earlier versions of the XENIX and UNIX systems, users should be aware of those places where their own programs could run up against these incompatibilities.
The clocks on the NFS server and client may be out of sync because each machine keeps its own time. This might cause problems. Consider the following example.
Many programs assume that an existing file could not be created in the future. For example, the command ls -l has two basic forms of output, depending upon how old the file is:
$The first type of output from ls prints the year, month, and day of last file modification if the file is more than six months old. The second form prints the month, day, hour, and minute of last file modification if the file is less than six months old.
dateSat Apr 12 15:27:48 GMT 1994 $
ls -l file*-rw-r--r-- 1 jsbach 0 Dec 27 1992 file -rw-r--r-- 1 jsbach 0 Apr 12 15:27 file2
The ls command calculates the age of a file by subtracting the modification time of the file from the current time. If the result is greater than six months, the file is ``old''.
Assume that the time on the server is Apr 12 15:30:31, which is three minutes ahead of the local machine's time:
$The difference between the current time and the library's modify time makes the ls command think that the new file was created long ago.
dateApr 12 15:27:31 GMT 1994 $
ls -l file*-rw-r--r-- 1 jsbach 0 Dec 27 1992 file -rw-r--r-- 1 jsbach 0 Apr 12 15:26 file2 -rw-r--r-- 1 jsbach 0 Apr 12 1994 file3
In general, users should remember that applications that depend upon local time and/or the filesystem timestamps have to deal with clock skew problems if remote files are used.