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:
>
> user.foo.sub %(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
user.foo.sub %(TYPE DELETED)
user.foo.sub %(TYPE DELETED)
user.foo.sub %(TYPE DELETED)
user.foo.sub %(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:
user.foo.sub %(TYPE DELETED)
user.foo.sub %(TYPE DELETED)
user.foo.sub %(TYPE DELETED)
user.foo.sub %(TYPE DELETED)
user.foo.sub %(NAMELOCK user.foo.sub TYPE RENAMELOCKED)
user.foo.new %(NAMELOCK user.foo.sub 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,
Thomas
