Bug with rename INBOX -> INBOX.blah and replication

[Ken Murchison]

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