What causes folders to be reported as noselect?
Daniel Miller
dmiller at amfes.com
Thu Sep 27 02:32:14 EEST 2018
On 2018-09-26 10:14, Aki Tuomi wrote:
>> On 26 September 2018 at 18:42 Daniel Miller <dmiller at 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...<pause here for head banging moment - see
other email>
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
More information about the dovecot
mailing list