Bug with rename INBOX -> INBOX.blah and replication

[Robert Mueller]

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?

Rob