2.4.6 reconstruct: timestamp mismatch which doesn't go away

Simon Matter simon.matter at invoca.ch
Wed Jan 19 04:18:49 EST 2011

> Hi,
> I've done some upgrades from 2.3.16 to 2.4.6 and it seems sometimes a
> reconstruct is the only way to get a mailbox work after upgrade. While
> running reconstruct two things have shown up which I have not seen wirh
> older releases:
> 1) on a mailbox which was used by a client reconstruct was just sitting
> there doing nothing. Seems like it was waiting for a lock to be freed?
> After terminating the client reconstruct would immediately resume it's
> work. Maybe that's expected, I'm just wondering how those with large
> number of users will reconstruct while the server is online? I mean, IIRC
> with older releases it was always possible to do a full reconstruct while
> users had access to their mailboxes. Is it not possible that way anymore?
> 2) I got some "timestamp mismatch" errors while reconstructing my own
> mailbox. I've read here
> http://www.mail-archive.com/cyrus-devel@lists.andrew.cmu.edu/msg01481.html
> that this should happen only once because the timestamp of the file should
> be corrected. That doesn't seem to be true in my case. Any ideas why?

OK, removing cyrus.index and doing the reconstruct makes the error go
away. But, I was thinking that the files mtime is set to what is found in
it's "Date:" field? That's however not the case as it seems. I'm really
not sure I understand the logic of which timestamp is stored where?
I see that utime() is called on the files while running reconstruct,
setting the already wrong mtime again?


More information about the Info-cyrus mailing list