On 25 Sep 2008, at 18:21, Bron Gondwana wrote:
. which looks for cases of MODSEQ being inappropriately set to 0 and
correcting it to be 1. Several buggy versions were released into
the
wild, so it's quite likely that there are MODSEQ 0 mailboxes out
there.
Xfer-ing them to a machine with this code in place will correct the
corruption. Xfer-ing them to a machine without this code in place
causes sync_client to die.
Interesting.. I thought I pushed a fix for this into 2.3.7
already, but
maybe that was only to stop imapd crashing.
As I'm sure you recall, there were *many* fixes to the MODSEQ code.
I'm not sure which versions had the bug which wrote MODSEQ 0, just
that I've got a lot of mailboxes that have it. A small percentage of
around 1M mailboxes. xfer-ing from a heavily patched 2.3.8 to
2.3.12p2 showed the problem -- replication doesn't permit MODSEQ to
be 0. This fix just checks for MODSEQ 0 during index upgrade, since
2.3.12 is an upgrade. A subtlety is that all mailboxes get upgraded
during xfer due to the change that sets mtime to INTERNAL during xfer.
I'll put this in bugzilla, anyway. I've already added:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2914
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3085
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3086
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3066
Rob suggests an imapd.conf option to control the new sieve utf-7
behavior discussed here:
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2008-September/
029778.html
Someone working on that? If there a bugzilla for it?
:wes
