Fixing stale entries in 'mailboxes.db'...

ellie timoney ellie at fastmail.com
Mon Mar 18 21:19:19 EDT 2019


On Tue, Mar 19, 2019, at 8:42 AM, Karl Pielorz wrote:
> 
> 
> --On 18 March 2019 at 12:34:12 +0100 Sebastian Hagedorn 
> <Hagedorn at uni-koeln.de> wrote:
> 
> >>   user.kpielorz.Archive.1-OldLogs    16 (null)
> >>
> >> [snip]
> >>
> >> Anyone seem similar, or know what can be done with them?
> >
> > I believe those are "tombstone entries" to mark folders that previously
> > existed and are are safe to keep around.
> 
> Ok, I'll leave them alone on that basis. Sadly we have far more of them 
> than active folders on the system, they must have built up over time (but 
> it's not like they're taking a lot of space / resources though).
> 
> I guess dumping mailboxes.db through grep -v etc. and re-importing would 
> remove them, but as I originally said I don't really want to do that on the 
> system.
> 
> Thanks for the reply,
> 
> -Karl
>

They're (briefly) important for recovering from split brain replication situations -- if one server has the mailbox and the other server doesn't, is it a new mailbox that needs to be created, or a deleted mailbox that needs to be deleted?  The tombstone records provide the answer.  If one server has the mailbox and the other has a tombstone for it, then it knows to delete the mailbox.  If one server has the mailbox and the other has nothing, then it knows to create the mailbox.

I'm not sure if they're also used for anything else -- possibly not in 2.5, but maybe in later versions.

They should be cleaned up by cyr_expire after they're 7 days old (this will eventually be configurable, but in 2.5 it is what it is).  This behaviour is turned _off_ by the '-x' argument, so if all your scheduled cyr_expire runs include the '-x' argument, nothing will clean them up...

Cheers,

ellie


More information about the Cyrus-devel mailing list