Deadwood is year-2038 compliant, even on systems with a 32-bit time_t. In order to pull this off, Deadwood assumes that 32-bit time_t systems showing a timestamp before May 6 2007 (chosen because it was 6 months before the first Deadwood release) have had their clock "wrap around" and that it's really far in the future, not far in the past.
This allows Deadwood to have accurate timestamps on systems with a 32-bit time_t until 2143. The side effect is that Deadwood assumes that systems with a timestamp of 0 are not in 1970, but instead are in the year 2106. This results in all records stored in the cache on systems with an incorrect timestamp not expiring until 2106.
If building Deadwood on a system which sometimes has an incorrect timestamp, there are a couple of ways to work around this:
- Run Deadwood on a system with a 64-bit time_t.
- Set up the system to not start up Deadwood unless the system clock
is set to May 2007 or later.
- Change the value of DW_MINTIME in DwSys.h to a lower or negative
value. Note that, if this is set, for example, to -1 instead of its
current value (1178488417: May of 2007), Deadwood will start to have
inaccurate timestamps on systems with 32-bit time_t in 2106, not 2143.
If this is done, please upgrade to a system with a 64-bit time_t
before 2106.
Please also note that dwh_put_int64() in DwHash.c (the code that writes the cache to disk) will not correctly store timestamps earlier than March 20, 1979 (they will simply be marked as being on that day). Such records in the cache should immediately expire on systems once the timestamp is correctly set, but this has not been tested at all.
It can be downloaded here:
http://www.maradns.org/deadwood/snap/
To post a comment about an entry, send me an email and I may or may not post your comment (with or without editing)