What causes folders to be reported as noselect?
As the subject says. This may be a bit open-ended - but it would really help troubleshooting some obscure folder issues.
In my case, I happen to have both some "real" folders and also some "virtual" folders that respond to IMAP LIST commands with the "\NoSelect" flag - and I don't know why. Via telnet, I can manually issue SELECT, SEARCH, and FETCH for such folders without errors.
--
Daniel
On 26 September 2018 at 18:42 Daniel Miller dmiller@amfes.com wrote:
As the subject says. This may be a bit open-ended - but it would really help troubleshooting some obscure folder issues.
In my case, I happen to have both some "real" folders and also some "virtual" folders that respond to IMAP LIST commands with the "\NoSelect" flag - and I don't know why. Via telnet, I can manually issue SELECT, SEARCH, and FETCH for such folders without errors.
--
Daniel
\NoSelect folders are usually namespace boundaries and non-existing folders, such as parents for children in systems where the parents do not need to exist for real.
You should not be able to SELECT a \NoSelect folder.
Aki
On 2018-09-26 10:14, Aki Tuomi wrote:
On 26 September 2018 at 18:42 Daniel Miller dmiller@amfes.com wrote:
As the subject says. This may be a bit open-ended - but it would really help troubleshooting some obscure folder issues.
In my case, I happen to have both some "real" folders and also some "virtual" folders that respond to IMAP LIST commands with the "\NoSelect" flag - and I don't know why. Via telnet, I can manually issue SELECT, SEARCH, and FETCH for such folders without errors.
--
Daniel
\NoSelect folders are usually namespace boundaries and non-existing folders, such as parents for children in systems where the parents do not need to exist for real.
You should not be able to SELECT a \NoSelect folder.
Aki
At the moment, the folders in question:
My primary namespace "inbox", with no prefix, has a folder INBOX, with a child folder "Other", which in turn has two children. "INBOX/Other" shows as \NoSelect - the two children are normal.
In my "virtual" namespace, I had a virtual folder defined as "Archives". I created a new folder "Archive-Search" and copied the dovecot-virtual file over - and it works fine.
I don't see anything wrong via filesystem permissions or ownership - so I'm assuming either there are reserved words I'm not allowed to use with IMAP folders (but I can't find any documented), or something in my namespace or folder setup is applying some kind of mask (or something is corrupted...more on this below), or...there's a bug. But I'm willing to assume the flaw lies with me. Or at least my ever wonderful server - which continues to keep me entertained instead of simply operating quietly and consistently without endearing quirks...
As far as selectability...
I was going to post a telnet session to prove I could...but when I tested previously I was using the "virtual/Archives" folder and it worked manually - before I created the "virtual/Archive-Search" folder and deleted the other. So I tried the "INBOX/Other" folder - and I do get the expected "NO Mailbox doesn't exist: INBOX/Other". So...
Just for fun...I created "virtual/Archives" again, copied the dovecot-virtual, set the permissions...and it works fine! And just in case...I also tried "virtual/Archive" - also now selectable. And to be clear - I create these folders directly in the filesystem, manually copy the dovecot-virtual file, and set the owner/permission.
Let's try another experiment...
Ok...moving on. "INBOX/Other" isn't selectable. Let's experiment a
little more carefully. Using RoundCubeMail, view the folder list,
rename "INBOX/Other" to "INBOX/Other-Old". Same conditions. Using
RoundCube - create a new folder "INBOX/Other" - this is now selectable!
Using RoundCube - move the first child of "INBOX/Other-Old" to
"INBOX/Other".
Now it's weird. INBOX/Other is present and selectable, INBOX/Other/Child1 is present and selectable - INBOX/Other-Old has disappeared and the former INBOX/Other-Old/Child2 is now at INBOX/Child2. Move that to INBOX/Other/Child2...now everything is selectable as expected.
Which leaves me wondering...what the <blank> was broken - and was there any other way to see it? The on-disk structure looked right and the IMAP folder lists looked right other than the non-selectability.
Daniel
participants (2)
-
Aki Tuomi
-
Daniel Miller