[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    Re: Replication and INBOX rename in 2.4.12
From:       Janne Peltonen <janne.peltonen () helsinki ! fi>
Date:       2012-08-30 13:36:45
Message-ID: 20120830133645.GF5287 () helsinki ! fi
[Download RAW message or body]

Um, sorry, folks, I hit "send" before I had a look at the "To" header. This
should have gone to our local list only.


--Janne / Univ. of Helsinki

On Thu, Aug 30, 2012 at 04:34:13PM +0300, Janne Peltonen wrote:
> T=E4m=E4 siis tiedoksi teillekin. Toki INBOX renamesta seuraavat jumituks=
et 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 an=
d 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 th=
e old
> > > circumvention method one more try, and lo and behold, it worked. I mu=
st'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_clien=
t and
> > have the same problem as before the removal:
> > =

> > --clip--
> > Aug 30 14:33:43 pcn1 i14/sync_client[10504]: RENAME received NO respons=
e: Operation is not supported on mailbox
> > Aug 30 14:33:43 pcn1 i14/sync_client[10504]: do_folders(): failed to re=
name: 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 pro=
bably
> > aren't that many USER operations on a mailbox in a row during normal op=
eration,
> > 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@helsinki.fi> PGP Key ID: 0x9CFAC88B
> =

> -- =

> Janne Peltonen <janne.peltonen@helsinki.fi> PGP Key ID: 0x9CFAC88B
> Helsingin yliopisto / Tietotekniikkakeskus
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

-- =

Janne Peltonen <janne.peltonen@helsinki.fi> PGP Key ID: 0x9CFAC88B
Please consider membership of the Hospitality Club (http://www.hospitalityc=
lub.org)
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
[prev in list] [next in list] [prev in thread] [next in thread]