Configuring the Network File System (NFS)

Clock skew in user programs

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:

   $ date
   Sat Apr 12 15:27:48 GMT 1994
   $ touch file2
   $ 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 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.

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:

   $ date
   Apr 12 15:27:31 GMT 1994
   $ touch file3
   $ 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

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.

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.