Bug with rename INBOX -> INBOX.blah and replication
murch at andrew.cmu.edu
Mon Dec 4 19:42:52 EST 2006
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: RENAME received NO
> response: Rename failed user.pinguser254 -> user.pinguser254.blah:
> Operation is not supported on
> Dec 4 19:33:26 imap3 slot309/sync_client: do_folders(): failed
> to rename: user.pinguser254 -> user.pinguser254.blah
> Dec 4 19:33:26 imap3 slot309/sync_client: 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
> 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?
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.
Project Cyrus Developer/Maintainer
Carnegie Mellon University
More information about the Info-cyrus