14. 10. 2020 v 11:51, Victor Sudakov <vas at sibptus.ru>:> >> I had to do it with 10-20 live users and it went fine, nobody noticed >> anything (I made the change in the night hours just to be sure >> though). I had to go down and fix some erratic folder names that >> resulted from the botched separator handling on some macOS Mail >> accounts. > > Did it change anything on Dovecot disk/storage or is the IMAP separator just > "virtual" - ephemeral ?Changing the separator won't fix anything that already exists. You should see nonsense folders in the form of '.folder\2esubfolder? there that cannot be worked with in any way. I manually moved the contents of these to their properly named ('.folder.subfolder?) variants - on disk. -F
Filip Hajn? wrote:> > > >> I had to do it with 10-20 live users and it went fine, nobody noticed > >> anything (I made the change in the night hours just to be sure > >> though). I had to go down and fix some erratic folder names that > >> resulted from the botched separator handling on some macOS Mail > >> accounts. > > > > Did it change anything on Dovecot disk/storage or is the IMAP separator just > > "virtual" - ephemeral ? > > Changing the separator won't fix anything that already exists. You should see nonsense folders in the form of '.folder\2esubfolder? there that cannot be worked with in any way. I manually moved the contents of these to their properly named ('.folder.subfolder?) variants - on disk.Thanks for the warning Filip! -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 at fidonet http://vas.tomsk.ru/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: <https://dovecot.org/pipermail/dovecot/attachments/20201014/bb9a74ee/attachment-0001.sig>
Filip Hajn? wrote:> 14. 10. 2020 v 11:51, Victor Sudakov <vas at sibptus.ru>: > > > >> I had to do it with 10-20 live users and it went fine, nobody noticed > >> anything (I made the change in the night hours just to be sure > >> though). I had to go down and fix some erratic folder names that > >> resulted from the botched separator handling on some macOS Mail > >> accounts. > > > > Did it change anything on Dovecot disk/storage or is the IMAP separator just > > "virtual" - ephemeral ? > > Changing the separator won't fix anything that already exists. You should see nonsense folders in the form of '.folder\2esubfolder? there that cannot be worked with in any way. I manually moved the contents of these to their properly named ('.folder.subfolder?) variants - on disk. >I was asking because the section "Hierarchy separators" in https://doc.dovecot.org/configuration_manual/namespace/ somewhat implies that However, changing the separator doesn?t change the on-disk ?layout separator?. That's why I thought that the separator is in fact virtual. At present, if my folder layout in the mail client is Inbox | +---Friends | +----Paul | +----Jessica the folder "Jessica" on-disk is something like ~/Maildir/.Friends.Jessica/{cur,new,tmp}/ Do you mean to say that if I change the IMAP separator to "/", Dovecot will not translate "/" into "." and the folder "Jessica" will become inaccessible? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 at fidonet http://vas.tomsk.ru/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: <https://dovecot.org/pipermail/dovecot/attachments/20201014/d0654f99/attachment.sig>
On 14.10.20 15:02, Victor Sudakov wrote:> I was asking because the section "Hierarchy separators" in > https://doc.dovecot.org/configuration_manual/namespace/ somewhat implies > that > > However, changing the separator doesn?t change the on-disk ?layout separator?. > > That's why I thought that the separator is in fact virtual.You're right - please see my former mail and the link you repeated above. There's a nice table which shows the possible combinations of hierarchy separator (called 'NS sep' there) and 'Layout sep' (structure on disk) and the respective results for 'Mailbox name' and the directory structure in the filesystem.> At present, if my folder layout in the mail client is > > Inbox > | > +---Friends > | > +----Paul > | > +----Jessica >> the folder "Jessica" on-disk is something like ~/Maildir/.Friends.Jessica/{cur,new,tmp}/-------------------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then you have configured a Layout sep '.' (mail_location = maildir:~/Maildir). This says nothing about your hierarchy separator, which is controlled by the parameter 'separator ='.> Do you mean to say that if I change the IMAP separator to "/", Dovecot > will not translate "/" into "." and the folder "Jessica" will become > inaccessible?If you currently have 'separator = .' then of course the hierarchy separator is '.'. If you change that to 'separator = /' normally the access to "Jessica" is still possible. But (as you can see in the table mentioned above) the name of the mailbox (= folder) from the IMAP clients point of view is now 'Friends/Jessica'. Before the change and with 'separator = .' the name of the mailbox was 'Friends.Jessica'. If you telnet to Dovecot and (after authentication) type something like this: a LIST "" "*" The server may responds with: * LIST (\HasChildren) "." INBOX Here you can see, that this name space has a '.' as the hierarchy separator. If the response is this: * LIST (\HasChildren) "/" INBOX then we know that '/' is the hierarchy separator. So, if you have an IMAP client which ist standard-compliant he will check what's the configured hierarchy separator and will use it for accessing the folder structure. And again: this has nothing to do with the on disk structure of the folders. Regards, Markus