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 br...@fastmail.fm