[ntp:questions] Re: NTP, Unix and the 34-year itch (better read this)
terje.mathisen at hda.hydro.com
Fri Jan 23 08:23:01 UTC 2004
Simon Burge wrote:
> Harlan Stenn wrote:
>>One could certainly use the timestamp on that file as *a* way to try and
>>find the ballpark, but as I recall the embedded systems folks often have
>>problems writing files like that and want to avoid them.
> Note that we already have some date info in the ntpd binary - the
> version string from version.c. From a recent build:
> "ntpd 4.2.0a at 1.1210-r Wed Jan 14 01:33:04 EST 2004 (1)"
> Maybe this can somehow be used in a sanity check?
It could indeed be used, and if the date stamp of the ntp.drift file is
not more than a reasonable number of years ahead of it, the drift file
timestamp could extend the range even further.
However, simply setting a basic requirement that the initial time _has_
to be greater than the build time, would be sufficient to get into the
proper 136-year epoch.
Even if that should optimally be 1/2 (68 years) or 1/4 (34 years) the
full range, I really cannot see a way to run an unmodified binary for
more than 34 years, much less 68 or 136!
Even if you absolutely cannot modify the ntpd binary code, hex-editing
the string to update the year should be fefasible even for embedded devices.
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
More information about the questions