Replication and INBOX rename in 2.4.12

[Janne Peltonen]

Tämä siis tiedoksi teillekin. Toki INBOX renamesta seuraavat jumitukset saa
jatkossakin korjatuksi, seuraavaan USER-operaatioon asti... :(


--Janne

On Thu, Aug 30, 2012 at 04:33:18PM +0300, Janne Peltonen wrote:
> 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

-- 
Janne Peltonen <janne.peltonen at helsinki.fi> PGP Key ID: 0x9CFAC88B
Helsingin yliopisto / Tietotekniikkakeskus