Robust atomic multiple folder rename

[Bron Gondwana]

On Wed, Jan 22, 2014, at 02:19 AM, Thomas Jarosch wrote:
> Hi Bron,
> 
> On Thursday, 2. January 2014 09:52:13 Bron Gondwana wrote:
> > user.foo.sub         %(NAMELOCK user.foo.sub TYPE RENAMETEMP)
> 
> I just came up with a case that fails at least in cyrus 2.4:
> 
> Rename a user while a mailbox is currently in SELECT state.

This doesn't fail in 2.5/master, because it unlocks the mailbox
entirely between cmdloop cycles.  So 

> Cyrus 2.4 will execute the mailbox rename, but leave the folder
> of the selected mailbox still floating around on the filesystem.
> The cyrus.* files are still present, too.

Yep.  In theory, the process that's holding it open will clean it up.

> As far as I understand it, the new system will just keep the folder
> in "RENAMETEMP" state and remove it later on. Right?

The SELECTed processes will freeze when they hit one of these folders,
waiting on the lock that's being held by the process doing the rename.
If they get the lock and it's still in the RENAME state, then obviously
the renaming process crashed, so it will perform a rollback of the
rename.

Obviously, if they get the lock and the folder has changed to type
DELETED, then they'll do the normal thing on a deleted folder.

Cheers,

Bron.



-- 
  Bron Gondwana
  brong at fastmail.fm