> On 06 Jan 2016, at 15:35, Timo Sirainen <[email protected]> wrote: > > On 06 Jan 2016, at 11:47, Peer Heinlein <[email protected]> > wrote: >> >> >> We're running a huge imapc-Migration from an old Courier-IMAP to Dovecot. >> >> Courier always uses "INBOX."-prefix for his folders, so we set >> >> namespace inbox { >> [...] >> separator = . >> prefix = INBOX. >> [...] >> } >> >> on our new Dovecot 2.2.20 system. >> >> And also we added: >> >> imapc_list_prefix=INBOX >> >> to avoid the dublication of the INBOX prefix. >> >> At the end, doveadm/dsync/imapc see "INBOX.Virus", adds his Prefix, has >> "INBOX.INBOX.Virus", deletes his imapc_list_prefix and the end we have >> "INBOX.Virus" again which is identical to the source folder from Courier. >> >> Works perfect BUT: >> >> It looks like there is a "hidden feature" in Dovecot that always maps >> "INBOX.INBOX" back to "INBOX". For me that looks like a workaround for >> broken mailclients to fix some of the common problems after changing the >> namespace prefix. >> >> I never heard about that "hidden feature", but even if I don't (!) have >> INBOX.INBOX: >> >> root@imap01:~/MIGRATION # doveadm mailbox list -u test >> INBOX >> INBOX.Virus >> INBOX.Spam >> INBOX.Trash >> >> I'm always able to access INBOX.INBOX which is identical to INBOX: >> >> root@imap01:~/MIGRATION # doveadm fetch -u test uid mailbox INBOX.INBOX >> uid: 1 >> >> Looks like there is such a magic-mapping and looks like this "hard coded >> mapping" (?) breaks the imapc_list_prefix-magic. >> >> If the user has on the SOURCE-server (Courier): >> >> Source-Server: >> INBOX (5 messages) >> INBOX.Inbox (3 messages) >> >> and I do migrate that user using doveadm/dsync/imapc, this user has on >> the DESTINATION-server (Dovecot) >> >> Destination-server: >> INBOX (5 messages) >> INBOX.Inbox (5 messages from "real INBOX") >> >> and his 3 messages from INBOX.Inbox are lost. >> >> I can NOT find any errors in the debug/error-output of >> doveadm/dsync/imapc. From the view of doveadm everything worked perfect >> as you can see in the attached logfile. >> >> Or am I completly wrong?! > > It's not really a "hidden feature", but more likely a consequence of the > INBOX. prefix being added/removed from folder names. I'd need to look into it > more carefully to see if it's possible to fix easily or not, but I have a > feeling it may not be easy. INBOX.INBOX has caused troubles many times > earlier.. One solution that should work is that for dsync runs you'd simply > remove the INBOX. prefix from both the namespace and the imapc_list_prefix.
Or actually that would just add INBOX. prefix to everything. Maybe removing either namespace prefix or imapc_list_prefix would work?
