*IMPORTANT* - bugfix sync_append_commit index breakage

[Ken Murchison]

Bron Gondwana wrote:
> On Sat, 01 Sep 2007 13:08:00 -0400, "Ken Murchison" <murch at andrew.cmu.edu> said:
>> David Carter wrote:
>>> On Sat, 1 Sep 2007, Ken Murchison wrote:
>>>
>>>> I applied this patch to CVS, but I'm wondering why the original code 
>>>> writes directly to the existing cyrus.index instead of a 
>>>> cyrus.index.NEW, as is done in other places.  I don't know if this was 
>>>> intentional by the previous authors, or an oversight.  I'm going to 
>>>> investigate.
>>> Doesn't cyrus.index.NEW only kick in on expunge?
>> I believe so.  If we also used it for appends, we wouldn't run into the 
>> problem that Fastmail is seeing.  But, it may be too much of a 
>> performance hit.
> 
> Speaking of which, is there any reason why cyrus.expunge isn't sorted
> by UID?  We have to rewrite the entire cyrus.index each time we do an
> expunge anyway.

True, but do you want to rewrite the entire cyrus.expunge for every 
expunge too?  Right now, we just append to cyrus.expunge to make expunge 
as quick as possible, which was the original intent.


> Sorted by UUID would help enormously for things like not blatting the
> \Seen state for expunged messages until they're expired, because you
> could then just do a double-iterator over the two "index format" files.

Seen state gets goofed up on unexpunge because we don't keep the 
original UID.  I wanted to, but re-injecting a message in the middle of 
a mailbox with a UID < UIDNEXT was either a violation of RFC3501 and/or 
seriously screwed with clients.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University