On Wed, Mar 25, 2009 at 11:55:09AM -0300, Patrick Boutilier wrote:
> David R Bosso wrote:
>> --On March 13, 2009 10:18:53 AM -0300 Patrick Boutilier
>> <boutilpj@xxxxxxxxxxx> wrote:
>>
>> <snip>
>>
>>>> This will be real easy to test though. I will just run ipurge on a
>>>> subfolder of my mailbox and see if it corrupts it. :-)
>>
>> FWIW we see the same corruption here with ipurge. We use ipurge to
>> clean out old messages from a spam box for each user. We've worked
>> around it currently by reconstructing the box after the ipurge which
>> adds a lot of work to our nightly maintenance.
You know - I can't see, from an immediate code reading, how this is
happening. It's just calling "mailbox_expunge" with an immediate
FORCE and a decideproc.
Hmm.. of course, that rewrites the .cache file, but doesn't rewrite
the .expunge file. DUH! Colour me an idiot.
Yep, bug fully understood :) While I'm sitting here on the train
typing in fact! I'll have a think about the best way to handle
this. It's 99% totally un-necessary, because the cache pointers
in the cyrus.expunge file aren't really needed anyway (rebuilding
the cache record on unexpunge would not be the end of the world),
but the current state of affairs is clearly bogus.
> Plus you lose all the messages that are in "delayed expunge" state after
> running a reconstruct. :-(
RFTM -k
Bron ( the simple and safe solution would be to not pass EXPUNGE_FORCE
during ipurge, in which case the disk would be cleaned up by
your regularly scheduled cyr_expire, and you could even unexpunge
ipurged messages )
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
