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
