unified murder gets mailboxes list truncated

[Janne Peltonen]

On Sat, Jun 30, 2007 at 03:16:30PM +0300, Janne Peltonen wrote:
> b) run ctl_mboxlist -m -a
> Option b) might be more interesting (I haven't tried it out yet). The
> man page says that "assume the local mailboxes file is authoritiative,
> that is, only change the mupdate server, do  not  delete  any  local
> mailboxes.  USE THIS OPTION WITH CARE, as it allows namespace collisions
> into the murder" - now I wonder whether the remote mailbox entries will
> still be deleted... Well, I'd better try it out next. Reports to follow.

Well. Running ctl_mboxlist -m -a didn't truncate the mailboxes list, but
it took relatively long to complete (21 minutes with only one cluster
member doing it - on the other hand, since the ctl_mboxlist wasn't busy
writing this time, the time required to do the ctl_mboxlist will
probably stay the same regardless of the number of members doing it).
Additionally, the -a option really does as it says - the local mailboxes
list is authoritative. That is, it's authoritative over the complete
murder (which I find very strange) - if I delete a remote folder from
the local mailboxes list, then do ctl_mboxlist -m -a, the master records
the deletion and propagates it forward... the mailbox disappears from
the complete murder.

So there seems to be no way to get a unified murder up and running so
that there isn't some risk of information loss - actually, I already
knew this; there is a constant running risk of information loss if the
mailboxes list on a running murder's mupdate master gets corrupted (the
corrupted list if propagated to all the members) and the backups are
lost. It'd be really really nice if somebody changed the ctl_mboxlist
and mupdate slave code so that if the murder config is unified, the
local server is authoritative on local mailboxes - and /only/ on local
mailboxes.

I wonder if it's too late to convert my murder to a traditional one...


--Janne