User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 My IMAP server (dovecot) allows nested folders. I get an error dialog if I try the following: Suppose I have a folder 'X' with a sub-folder 'Y'. I expand 'X' so that 'Y' is visible and select 'Y'. I then collapse 'X'. Now thunderbird attempts to select folder 'X' (since 'Y' is no longer visible and cannot remain selected.) My IMAP server tells thunderbird that 'X' doesn't exist. Since the only contents of 'X' is a single sub-folder, I'm guessing that dovecot doesn't consider it an actual folder that can be selected. I'm not certain whether this is the correct behavior by dovecot or not, but it is pretty annoying to be reminded of this every single time I do it. I use nested folders a lot and keep them collapsed to save on screen real-estate, so I have to click through this dialog a lot of times. I do not see this problem with evolution. Note that if I select the folder myself (instead of going through the collapse technique I just described) I also get the same error message. Reproducible: Always Steps to Reproduce:
Oops - I forgot the mention the symptom: when dovecot tells thunderbird that the folder doesn't exist, I get a message from thunderbird saying "The current command did not succeed. The mail server responded: Mailbox isn't selectable: X' My suggestion is to not display this if you know the folder contains sub-folders.
it could be that dovecot doesn't support folders that can contain messages and have sub-folders. If so, try telling us that - tools | account settings | imap server | advanced - uncheck "server supports folders..." An imap protocol log would tell us if the dovecot server is actually telling us that the folder is /NOSELECT. My guess is that it's not. http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Created attachment 175956 [details] Log of imap transactions I tried turning that option off, but it made no difference. Attached is the IMAP log. You can see on line 2913 the error message (the top-level folder containing all the sub-folders is called "linux".)
from that log, the server isn't telling us in the LSUB response that the folders are /NOSELECT. Technically, I think they only have to tell us that in the LIST response but most servers give the same set of flags from LSUB as LIST, or at least the important ones. You could try switching off subscription in the same advanced server settings, and see if the server returns the /NOSELECT flag from LIST. Or maybe just bringing up the subscribe UI will cause us to set the /NOSELECT flag in the db...
Well that's an improvement, but only soft of. I unselected the subscription option, quit and re-entered thunderbird and voila, a big violin. The top-level folders are now all grayed out and unselectable, and I no longer receive this error message. However, I now get every single folder in the locations where IMAP looks, including ones that have nothing to do with mail. I know that's what the option is for, but it seems the option and the behavior are only slightly related. For some reason, thunderbird gets the knowledge of selectability of the folder when this option is not set, but should be getting it all the time. Also, for some reason I haven't figured out yet, unsetting this option effected the sub-folders of a second account I have configured. I didn't touch the settings for that second account, but it had the almost exact same behavior: top-level folders that contained only sub-folders are greyed out. The weird thing is that they now remain that way even after turning the option back on again for the first account, quitting and re-entering the program.
Same bug with a Cyrus server. The server responds like this b lsub "" "%" * LSUB () "." "sent-mail" * LSUB () "." "stuff" * LSUB (\Noselect \HasChildren) "." "~ Public Folders" Two Tbird users configured to show only subscribed folders report that it tried to open "~ Public Folders" despite the \Noselect, giving the error "Invalid mailbox name". Does Tbird actually implement the \Noselect tag at all? If not then there is no mystery here. Interesting note: For the user whose output is shown above, "~ Public Folders" is not, in fact, subscribed, but rather two sub-folders in it are subscribed. Is this confusing?
Same bug with uw imap server (and under Windows, btw). Normally, this doesn't occur because TBird doesn't allow you to subscribe to NoSelect folders. So one way to fix this is to unsubscribe the NoSelect folder, TBird will know about the directory structure. However, other clients might need the folders subscribed to show the directory structure (I have this problem with Squirrelmail, for example), so you can only work with one of the clients without problems. Finally, the uw imap server doesn't report the NoSelect flag in LSUB, only in LIST, so checking for the flag only in LSUB is not sufficient.
I found out how to fix the problem with uw imap: In uw imap, subscribed folders are listed in the .mailboxlist file. TBird does allow subscribing folders that have subfolders. However, they need to be listed with a trailing slash (like "Mail/Private/"), whereas without the trailing slash (like "Mail/Private") TBird thinks it's a message-only folder and gives the error reported originally. If you only use TBird, the problem never occurs. If, however, you also use other mail programs that subscribe folders but don't put the trailing slash, then you will see the error. (In reply to comment #7) > Same bug with uw imap server (and under Windows, btw).
Reporter, does the issue still occur with the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported Thunderbird version 2 is 188.8.131.52)
Whiteboard: closeme 2008-08-28
RESO INCO per lack of response to the last question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
This is still not resolved.
How can I reopen this bug? There is no option for it.
Please file a new bug rather than revisiting a 5-6 year old issue.
(In reply to Patrick Schoenbach from comment #13) > How can I reopen this bug? There is no option for it. after you create the new bug report, please come back here and post the new bug#
I opened a new bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1017005
You need to log in before you can comment on or make changes to this bug.