I fixed this problem by having Deadwood compare the timestamp for the dwood3rc file and the cache file; if the cache file is older than the dwood3rc file, Deadwood will now refuse to load the cache.
As it turns out, the interface for stat() that I use is identical in Windows and *NIX. Another thing: I now understand why *NIX fanatics hate it when you say that st_ctime is the creation time of the file: In Windows, st_ctime is, indeed, the file's creation time. However, in *NIX, it's the last time the inode (meta-information) for the file was changed.
Here's an interesting question: Does the file's st_ctime change if the files contents are changed, but no inode information is changed? Of course, since the file's size and atime is in the inode, then I would say st_ctime changes every time the file is changed. Indeed, since inode information is changed every time the file is accessed, I think it would make sense to change the st_ctime every time we change st_atime (the last time a file was accessed).
st_ctime really should have been the file creation time if you ask me. Windows, not *NIX, gets this right.
All of this, of course, is academic; Deadwood looks at st_mtime to verify the cache is newer than the dwood3rc file.
It can be downloaded here:
http://www.maradns.org/deadwood/snap/I plan to work on MaraDNS/Deadwood again one day in December, after the 20th, unless a critical security bug with a CVE number is found.
In order to reduce spam, comments for this entry are now closed