Another cache bug!

[Bron Gondwana]

Wow, this is the thanks I get for doing sanity checks on files, find more bugs!

This one is due to delayed expunge, plain and simple.  Cyrus decides what cache
records to copy during an IMAP COPY command by reading the cache offsets for
msgno and msgno+1 (or the end of the cache file if it's the last msgno).

Obviously if some intervening messages have already been deleted from the
cyrus.index then it will be copying all those cache records as well to the
destination folder.  Oops.

The attached patch reworks mailbox_cache_size into two functions, the second
being mailbox_cache_size_detail that takes memory locations for the cache mmap
rather than a mailbox object (because imapd doesn't update the locations in
the object correctly according to my testing, *sigh*.  Gotta love global
variables)

It then uses mailbox_cache_size_detail to calculate the ACTUAL record length
for this single cache item rather than blindly copying everything up to the
next index record's pointer.

Also note: in the event of cache corruption, mailbox_cache_size_detail returns
zero bytes, which correctly makes append_copy re-parse the message file.  It's
all shiny :)

Wes/Ken - please apply to CVS :)

Thanks,

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-copy-cachelen-2.3.13.diff
Type: text/x-patch
Size: 3530 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20081210/7e67bc3c/attachment.bin