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