Support this website or
listen to my music
New Deadwood snapshot
January 6 2012
Here's a new FAQ question and answer for Deadwood:
Records added to the cache when the timestamp is set to 1970 do not
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
) 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
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.
I have updated the Deadwood docs to include this information.
It can be downloaded here:
To post a comment about an entry, send me an email and I may or may
not post your comment (with or without editing)
Previous entry -
Next entry -