Robert Mueller wrote:
Hi Ken
There's a bug with replication and renaming INBOX -> INBOX.blah.
From http://www.ietf.org/rfc/rfc3501.txt:
Renaming INBOX is permitted, and has special behavior. It moves
all messages in INBOX to a new mailbox with the given name,
leaving INBOX empty. If the server implementation supports
inferior hierarchical names of INBOX, these are unaffected by a
rename of INBOX.
Doing this in cyrus succeeds:
. rename INBOX INBOX.blah
. OK Completed
But causes replication to bail out:
Dec 4 19:33:26 imap3 slot309/sync_client[32088]: RENAME received NO
response: Rename failed user.pinguser254 -> user.pinguser254.blah:
Operation is not supported on
mailbox
Dec 4 19:33:26 imap3 slot309/sync_client[32088]: do_folders(): failed
to rename: user.pinguser254 -> user.pinguser254.blah
Dec 4 19:33:26 imap3 slot309/sync_client[32088]: Error in do_sync():
bailing out!
Neither does a sync_client -u fix it:
$ sudo -u cyrus ~cyrus/bin/sync_client -C /etc/imapd-slot309.conf -v -u
pinguser254
USER pinguser254
Error from do_user(-C): bailing out!
Looks like this is because the new mailbox has the same internal unique
id as INBOX, which causes the other end to get confused on the renaming
of it. It seems to me the solution is to give the new mailbox a new
unique id?
Hi Rob,
This is already a known problem (bug #2727?). I haven't come up with a
"clean" fix yet, although I haven't thought about it much.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
