Replication woes with a specific mailbox...
We had a strange exception here, a user's inbox could be replicated without problems, but doing it for a second time does not do it. sync_client was invoked like this: sync_client -v -u X Jul 28 10:52:17 priscilla sync_client[21326]: RENAME received NO response: Rename failed user.X - user.X.Uni: Operation is not supported on mailbox Jul 28 10:52:17 priscilla sync_client[21326]: do_folders(): failed to rename: user.X - user.pX.Uni Jul 28 10:52:17 priscilla sync_client[21326]: Error in do_user(X): bailing out! sync_client seems to try to RENAME the Inbox to the subfolder Uni which is complete nonsense. It is the only mailbox where this appears. Replicating in mailbox mode does work however. I did a mailboxes.db-Dump (ctl_mboxlist -d) and could not find any inconsistencies with that user's mailboxes, including the one named Uni. Anyone had the same problem? :) Difficult to submit a bug report because I can't tell the exact condition when this appears. The username was replaced by X for privacy reasons. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication woes with a specific mailbox...
On Fri, 28 Jul 2006, Pascal Gienger wrote: sync_client seems to try to RENAME the Inbox to the subfolder Uni which is complete nonsense. Do the mailboxes have the same UniqueID (see cyrus.header files)? The replication engine expects UniqueID to be unique. Cyrus makes a bit of a hash of renaming user inboxes (user.XXX - user.XXX.Uni). Removing the cyrus.header file and running reconstruct should fix the problem. -- David Carter Email: [EMAIL PROTECTED] University Computing Service,Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication woes with a specific mailbox...
David Carter [EMAIL PROTECTED] wrote: Do the mailboxes have the same UniqueID (see cyrus.header files)? The replication engine expects UniqueID to be unique. Cyrus makes a bit of a hash of renaming user inboxes (user.XXX - user.XXX.Uni). Removing the cyrus.header file and running reconstruct should fix the problem. That fixed the problem. Thank you! I wonder why these IDs were unique... Pascal Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Replication woes with a specific mailbox...
On 28 Jul 2006, at 05:48, Pascal Gienger wrote: David Carter [EMAIL PROTECTED] wrote: Do the mailboxes have the same UniqueID (see cyrus.header files)? The replication engine expects UniqueID to be unique. Cyrus makes a bit of a hash of renaming user inboxes (user.XXX - user.XXX.Uni). Removing the cyrus.header file and running reconstruct should fix the problem. That fixed the problem. Thank you! I wonder why these IDs were unique... We caused that problem in a couple of ways. Most commonly, when we migrated the data from other campus IMAP servers. The other common cause has been restoring from tape. In both cases, admins routinely copy cyrus.header from the INBOX into the newly populated folder. Our new procedure is the same, with the additional steps of removing the freshly copied cyrus.header after reconstructing and then reconstructing again. In the first reconstruct inserts the mailbox into the mailboxes.db. In the second reconstruct, since mailboxes.db lists the folder, reconstruct will recreate the cyrus.header. You should also be aware that the mailbox ID is the index in the seen database for the user, so replication isn't the only thing that's impacted by having non-unique mailbox IDs. :wes Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
