User-Agent: Build Identifier: Mozilla Thunderbird 0.4 (20040127) When an IMAP account has folders nested more deeply than two levels, the folders beyond that are not remembered properly by Thunderbird; they disappear from the folder tree pane (but can be brought back by collapsing and re-expanding the top-level foler) and their contents are forgotten (Thunderbird downloads the complete header list from the IMAP server). This happens with both Courier-IMAP and BincIMAP servers. Reproducible: Always Steps to Reproduce: 1. Create an IMAP account with nested folders more than two levels deep. 2. (Optional) Put some emails in the nested folders. 3. Expand all the branches in the tree-view folder pane. 4. Exit Thunderbird. 5. Run Thunderbird. 6. Type in the password for the IMAP account. Actual Results: At #5, the folders pane displays all the folders correctly. After the login to the IMAP server is completed successfully at #6, any folders deeper than two levels disappear. Collapsing and re-expanding the tree for the top-level folder causes these sub-folders to be correctly displayed again. Clicking on one of the disappearing folders causes Thunderbird to download the headers for the folder again. Clicking on one of the non-disappearing folders does not, showing that Thunderbird has remembered the contents of these folders. Note: Step 3 is not necessary to reproduce the problem, but is necessary to show that Thunderbird remembers that the folder exists until the login to the IMAP server is complete. Note: If step 6 is never completed, ie the cancel button on the password dialog is pressed, the folders never disappear. The connection to the IMAP server must complete successfully to reproduce this problem. Expected Results: Third-level or deeper folders should behave in the same way as second- or top-level folders; they should be displayed in the expanded view after IMAP login and their contents should be cached. This bug does not prevent the use of the software with deeply nested IMAP folders; the workaround is to collapse and expand the folder tree which causes Thunderbird to display the folder properly. However, in cases where deeply nested folders contain more than a few hundred messages, having to download all the headers for those deep folders every time the application starts is extremely annoying and time-consuming.
According to ethereal, the problem is that Thunderbird doesn't request the information about folders deeper than two levels. The relevant part of the IMAP conversation follows: 2 OK LOGIN Ok.. 3 namespace. * NAMESPACE (("INBOX." ".")) NIL (("shared." ".")). 3 OK NAMESPACE completed.. 4 list "" "INBOX.%". * LIST (\HasNoChildren) "." "INBOX.Trash". * LIST (\HasChildren) "." "INBOX.Toplevel". * LIST (\HasNoChildren) "." "INBOX.Sent". 4 OK LIST completed.. 5 list "" "INBOX.%.%". * LIST (\HasChildren) "." "INBOX.Toplevel.Level2a". * LIST (\HasNoChildren) "." "INBOX.Toplevel.Level2b". 5 OK LIST completed.. 6 list "" "shared.%". 6 OK LIST completed.. 7 list "" "shared.%.%". 7 OK LIST completed.. 8 list "" "INBOX". * LIST (\Unmarked \HasChildren) "." "INBOX". In this example, the folder Toplevel.Level2a.Level3 exists and displays the behaviour explained in this bug. Although the IMAP server reports that Toplevel.Level2a "HasChildren", Thunderbird never issues a '5 list "" "INBOX.%.%.%".' (or similar) to get its details. This appears to cause Thunderbird to assume that the Toplevel.Level2a.Level3 folder doesn't exist; it then deletes the ~/.thunderbird/default/z19392dd.slt/ImapMail/localhost/Toplevel.sbd/Level2a.sbd/Level3.msf file, forcing it to download the header list all over again.
*** This bug has been marked as a duplicate of 219498 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.