Network Time-keeping

[Glenn S. Fowler]

In article <1991Jun14.024635.15860 at cbnews.cb.att.com> junk1 at cbnews.cb.att.com (eric.a.olson) writes:
>    I maintain a couple of dozen 386/486s networked
>    together with RFS and use nmake viewpathing.   The current
>    reference area(s) might be on another machine.  I am capable
>    of syncing any machine to a common machine's time in seconds,
>    using tools I have found here and within AT&T.  However, no matter
>    how often I sync, it is not often enough to satisfy nmake.
>    In fact, more frequent sync seem to force recompiles more often.
>    A newer version of nmake will allow me to fudge the time within
>    a few seconds; however, this newer version has semantic differences
>    which make my current makefiles incompatible.

this may not be true for s5r4 (knowlegable input welcome), but for earlier RFS
a client and server negotiate system times when a client fs is mounted

	skew(client_mount) = time(server) - time(client)

then the skew is accounted for in the client struct stat st_?time fields

	st_mtime(client) = st_mtime(server) - skew(client_mount)

this way the server uses its own time to set st_?time but clients
see the files in their own time frame

this scheme is fine for the duration of a given mount, assuming that the
client and server times don't drift much after the initial mount
it also keeps make happy without doing network time syncs

the side effect is that st_mtime for a given file can change from one
RFS mount to the next *even though the file didn't change*

now consider nmake -- it keeps the state, including st_mtime, of all files
it checked from previous runs, so if the cilent and server times skew between
RFS mounts, even by just a second, then all of those files are out of date

the fudge time hack for RFS, mentioned above, treats times equal if the
difference is less than the fudge (if the fudge is too big then some
changes may go unnoticed)

first, this behavior breaks common sense file system semantics
second, the real solution (for the RFS vendor) is to drop the skew hack and
use a modern method to *keep the network times in sync*

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf at ulysses.att.com