232482 - IMAP sub-subfolders not remembered properly

Status: RESOLVED DUPLICATE of bug 219498

(Thunderbird :: Mail Window Front End, defect)

Description

[Tim Bates]

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.

Comment 1

[Tim Bates]

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.

Comment 2

[Scott MacGregor]

*** This bug has been marked as a duplicate of 219498 ***