Things for 2.3.13

[Wesley Craig]

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