Replication and INBOX rename in 2.4.12

[Janne Peltonen]

On Wed, Jan 18, 2012 at 01:25:08PM +0200, Janne Peltonen wrote:
> On Wed, Jan 18, 2012 at 12:19:57PM +0200, Janne Peltonen wrote:
> > What to do, how to circumvent this problem in the current version? I'd really
> > like to be able to be able to start replicating a user's mailbox and metadata
> > again, even if they have renamed their INBOX sometime in the past.
> Well, what do you know. Once I'd sent this mail, I decided to give the old
> circumvention method one more try, and lo and behold, it worked. I must've done
> something wrong the last three times I tried.
> So, not as acute as it appeared, just an inconvenience. Sorry.

Um. Apparently, not, after all. It seems that the sync_client -u works /the
first time/ after I've removed the user from the replica's mailboxes.db. But on
the second and all later runs I get 1 as a return value fron sync_client and
have the same problem as before the removal:

--clip--
Aug 30 14:33:43 pcn1 i14/sync_client[10504]: RENAME received NO response: Operation is not supported on mailbox
Aug 30 14:33:43 pcn1 i14/sync_client[10504]: do_folders(): failed to rename: user.<censored> -> user.<censored>.Saapuneet 
Aug 30 14:33:43 pcn1 i14/sync_client[10504]: IOERROR: The remote Server(s) denied the operation
--clip--

So why did I think I didn't have a problem? Apparently, since there probably
aren't that many USER operations on a mailbox in a row during normal operation,
I was content after that first USER operation.

***

Just upgraded my test boxen to Cyrus 2.4.16. The problem still persists. On my
way to file a bug...

Bug number 3734.

***

I am aware that there was another INBOX renaming related bug in 2.4.12,
reported by David Carter, that has been fixed in 2.4.13 (bug #3634). I never
saw that bug in my setup; this is something different.


Yours,
-- 
Janne Peltonen <janne.peltonen at helsinki.fi> PGP Key ID: 0x9CFAC88B