On Tue, Mar 19, 2019, at 8:42 AM, Karl Pielorz wrote:
> 
> 
> --On 18 March 2019 at 12:34:12 +0100 Sebastian Hagedorn 
> <haged...@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

Reply via email to