Bug with rename INBOX -> INBOX.blah and replication
robm at fastmail.fm
Mon Dec 4 19:39:05 EST 2006
There's a bug with replication and renaming INBOX -> INBOX.blah.
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():
Neither does a sync_client -u fix it:
$ sudo -u cyrus ~cyrus/bin/sync_client -C /etc/imapd-slot309.conf -v -u
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?
More information about the Info-cyrus