FastMail Cyrus Patches for upstream

[Brian Awood]

On Thursday 27 August 2009 @ 22:30, Bron Gondwana wrote:
>
> Yeah - it does make a bit more sense when you put it like that.
> Does it make 8 bytes per record worth of sense though? (we need
> to pad to 8 byte multiples for 64 bit modseq alignment.)  I'll have
> another look at that in a second.

It seems worth it to me, I suppose it might use slightly more ram, but 
the extra disk usage should be negligible. 

> Right - that would be a bug then.  I'll poke around the code.
> Just to confirm - the symptom is copied messages out of
> order causing the intermediate cache records to be copied
> as well?

Yeah, one place I noticed a problem was in index_copysetup(), there's
          CACHE_OFFSET(msgno+1) - CACHE_OFFSET(msgno);
and
	  cache_end - CACHE_OFFSET(msgno);

> Yeah, that's the problem though, because if the copied-back records
> might have the wrong offsets unless everything was kept in sync
> properly.

Remember that the index records contain the correct offset, but the 
cache records are "out of order".  So doing something like,
  CACHE_OFFSET(msgno+1) - CACHE_OFFSET(msgno)
returns a negative value.  It could also return too large of a value 
if there are UIDs in the expunged state in between msgno+1 and msgno.  
But it looks like using your cache_parserecord() instead should 
correct those issues.

Brian