10-12-2011 13:07, Timo Sirainen yazmış:
It could well be because of the conversion to sdbox then - the ctime/mtime of the files are not being preserved by dsync (in stock 2.0.16). The date.saved timestamp is only put into the cache on the second dsync run; presumably therefore it picks it up from the filesystem. With sdbox the file's mtime isn't even tried to be preserved. The received-time and saved-time are written to the metadata block inside the file.
Ah yes; I saw the R metadata but not the C header key. Looking deeper at this I think I was expecting the date.save time to be about the same as the date.receive; however the ctime for these files is quite recent presumably affected by setting of message flags in a maildir or something (we're using nfs). The source cache says:
- date.received: 1301978447 (4f9d9a4d)
- date.save: 1322465550 (0e39d34e)
The message file itself has mtime 1301978447 and ctime 1323514077; and in the sdbox header/metadata we have:
C4ee3391a R4d9a9d4f
so ctime/sdbox C entry are close enough by my calculations (not sure where the 61 seconds of difference comes from though). It is a bit strange you wouldn't use the source cache's value for date.save if it is available as ctime can be pretty unreliable?
Mark