reconstruct - mismatched timestamps

[Bron Gondwana]

On Mon, Oct 18, 2010 at 10:00:20PM -0400, Carsey, Robert wrote:
> I'm not really sure what happens with message timestamps.  I think it read's the message's fstat.st_mtime and compares it to a date inside the message?  Sometimes it reports that there is a mismatch and sometimes not.

Only happens once, because the new mailbox_append_index_record will
utime() the file on append.  Has the added benefit that it will throw
an IOERROR if it fails, so you never append when there's no file there
(modulo crashes and filesystem corruption, obviously)
 
> Apparently no problem with this guy's mailbox:
> 
> [root at hawkmail1 tmp]# reconstruct -G -r user.bretzger
> user.bretzger
> user.bretzger.DELETED
> user.bretzger.OUTBOX
> 
> But maybe there is:
> 
> [root at hawkmail1 tmp]# reconstruct -r user
> user: Mailbox does not exist (null)           (hmmm well ok, I guess this does not exist errmsg is legit)
> user.bretzger timestamp mismatch 2768
> user.bretzger timestamp mismatch 2769
> user.bretzger timestamp mismatch 2771
> user.bretzger timestamp mismatch 2836
> user.bretzger
> user.bretzger.DELETED
> user.bretzger.OUTBOX

Now that's very odd!  It should have discovered the issue the first
time as well...

> Ok so heres the timestamp and contents of one mismatched message.  I'm expecting reconstruct to either fix the st_mtime, or to report the mismatch no matter which way I run it.
> 
> 
> [root at hawkmail1 bretzger]# ls --full-time 2836.
> -rw------- 10 cyrus cyrus 12844 2008-09-18 13:29:38.000000000 -0400 2836.
> 
> First four lines of 2836.:
> 
> Return-Path: <emeritus-xxxxxx at mail.monmouth.edu>
> Received: from hawkmail.monmouth.edu ([unix socket])
>          by hawkmail.monmouth.edu (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA;
>          Thu, 18 Sep 2008 13:29:37 -0400
> X-Sieve: CMU Sieve 2.2
> Received: from mail.monmouth.edu (mail.monmouth.edu [192.100.64.12])
>         by hawkmail.monmouth.edu (8.13.1/8.13.1) with ESMTP id m8IHTYbV032125;
>         Thu, 18 Sep 2008 13:29:34 -0400
> Date: Thu, 18 Sep 2008 13:29:25 -0400

Yeah, that looks like a one second offset.  Depending on your configuration
the delivery either takes the timestamp from that header or just by calling
time(0) - but either way it should update the file modified time.

I could probably alter upgrade_index to call 'utime()' on every file so that
sites upgrading with a newer version get the file time modified up-front
rather than at reconstruct time.  That's probably a good idea in fact.  I'll
create a bugzilla bug for it.

Bron.