Robust atomic multiple folder rename

Thomas Jarosch thomas.jarosch at
Mon Jan 13 11:20:27 EST 2014

Hi Bron,

On Thursday, 2. January 2014 09:52:13 Bron Gondwana wrote:
> At this point, we go through all the old folder and delete the on-disk
> files.  Once that's done, we can do a single update in the mailboxes.db:
>         %(TYPE DELETED)
> (we keep DELETED tombstones in mailboxes.db now to ensure that UIDVALIDITY
> never gets reused, but also to detect the difference between "folder
> created on A" and "folder deleted on B" in a multi-master replication
> setup)

*snip* (looking good)

So I guess the flexible mboxlist format stores the UIDVALIDITY
in mailboxes.db (I haven't looked at in git yet).

Let's assume the user creates and renames a folder 
with the same name multiple times. We'll end up with multiple         %(TYPE DELETED)         %(TYPE DELETED)         %(TYPE DELETED)         %(TYPE DELETED)

entries in mailboxes.db. 

One corner case we should think of is if we recover
from a crash and mailboxes.db looks like this:         %(TYPE DELETED)         %(TYPE DELETED)         %(TYPE DELETED)         %(TYPE DELETED)         %(NAMELOCK TYPE RENAMELOCKED)         %(NAMELOCK TYPE RENAMETEMP)

As far as I can tell, the new scheme would work fine here, too.
We just need to be careful to ignore the "DELETED" entries
in all tools that juggle around the mboxlist entries.

Best regards,

More information about the Cyrus-devel mailing list