Mailbox deletion race: folders and files are never deleted

Samir Aguiar samir.aguiar at intra2net.com
Fri Feb 27 04:32:56 EST 2015


On Friday 27 February 2015 09:31:00 Bron Gondwana wrote:
> On Fri, Feb 27, 2015, at 06:31 AM, Jeroen van Meeuwen (Kolab Systems) wrote:
> > On 2015-02-26 16:51, Samir Aguiar wrote:
> > > Proposed solution:
> > > - Patch the mailbox_close() function to reload the index before trying
> > > to
> > > clean the files (and merge the current index changes with the ones
> > > found)
> > > - Because the above would still be skipped when shutting down Cyrus:
> > > expand
> > > cyr_expire to find mailboxes with the deleted flag set (by looping
> > > through the
> > > filesystem, and not by using the database) and try to remove them. This
> > > could
> > > then be run periodically by administrators.
> > > 
> > > What do you think?
> > 
> > Please do not take my word for it, but I think Cyrus IMAP 2.5 introduces
> > a state flag of MBTYPE_DELETE for mailboxes [1] in the actual mboxlist,
> > so the related functions would still be able to find it after the facts
> > of the case.
> > 
> > IIRC, I ran in to this (particular MBTYPE) because it purges ACLs, and
> > rendered (discrete) murder topologies unable to ctl_mboxlist -m (as well
> > as made ctl_mboxlist -d segfault).
> > 
> > I think the intention is exactly what you describe is the scenario, but
> > if it is I'm not certain it also properly addresses it.
> 
> Yes, MBTYPE_DELETE would help for this, that was my first thought.
> 
> Its main purpose is to enable true master/master replication and all the
> other good things like efficient JMAP mailboxListUpdates, but safe cleanup
> is a win too.
> 
> Bron.

That's great, we will then revisit this in 2.5.

Best regards,
Samir Aguiar


More information about the Cyrus-devel mailing list