Another cache bug!
David R Bosso
dbosso+lists.cyrus at lsit.ucsb.edu
Tue Mar 31 18:51:54 EDT 2009
--On December 10, 2008 10:36:56 AM +1100 Bron Gondwana <brong at fastmail.fm>
> Wow, this is the thanks I get for doing sanity checks on files, find more
> 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 :)
> Bron Gondwana
> brong at fastmail.fm
Going through my list of 2.3.13 patches to put together a local 2.3.14
build, I ran across this one. It doesn't appear to have made it into
2.3.14. Oversight, or is there something wrong with it?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3530 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20090331/a5f0f146/attachment-0001.bin
More information about the Info-cyrus