433837 - Limit of eight subfolders displayed in folderview.

Status: RESOLVED DUPLICATE of bug 249807

(Thunderbird :: General, defect)

Description

[Olaf J. Pauli]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 1.1.4322)
Build Identifier: Thunderbird 2.0.0.14 (20080421)

creating more than 8 subfolders folder 9 is not shown in folderlist. Folder 9 is allways created and could be seen in OE, Horde, Thunderbird 1.5.x.x, directly on server.


Reproducible: Always

Steps to Reproduce:
1.Create folder with Subfolders folder1/folder2/folder3 ... /folder8/???
2.After reaching limit of 8 subfolders, folder 9 is created on server but not shown in folderlist. Using Thunderbird 1.5.x the folder are displayed.
3.

Comment 1

[Jeff Beckley]

Works fine for me, with both Tb 2.0.0.14 and 3.0a1.

Can you get a protocol log of the conversation with the IMAP server?  Details on how to do it are here: <http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap>.

Comment 2

[Olaf J. Pauli]

Attachment: debug-output for IMAP

Debug-output by Thunderbird 2.00.14

Comment 3

[Olaf J. Pauli]

Attachment: debug-output 2 for IMAP

Debug-output for Thunderbird 1.5.0.12

Comment 4

[Olaf J. Pauli]

Debug-output for Thunderbird 2.0.0.14 (Win XP) and 1.5.0.12 (Fedora Core 6).
@Jeff
Please, have a look at line [stream=265e1c8 nb=143 needmore=0]
there's no 'has children', but there are.

Comment 5

[Olaf J. Pauli]

If you have a look at the folderlist, they are not shown.

Comment 6

[WADA:World Anti-bad-Duping Agency]

> Windows NT 5.1;
> debug-output for IMAP
> * LSUB () "." "INBOX.Ordner-01.Ordner-02.Ordner-03.Ordner-04.Ordner-05.Ordner-06.Ordner-07.Ordner-08.Ordner-09.Ordner-10.Ordner-11.Ordner-12"

It looks that "path length limit" of MS Windows(256 characters).

When Tb 2.0 on MS Win XP, ".msf" file for a mail IMAP folder is held in following directory, if profile is placed at default location.
> C:\Documents and Settings\<MS_Win_user_ID>\Application Data\Thunderbird\Profiles\<Random_String>.<Profile_Name>\ImapMail\<IMAP_Server_Name>
And when your deeply nested mail folder, ".msf" becomes next file under above directory.
> INBOX.sbd\Ordner-01.sbd\Ordner-02.sbd\Ordner-03.sbd\Ordner-04.sbd\Ordner-05.sbd\Ordner-06.sbd\Ordner-07.sbd\Ordner-08.sbd\Ordner-09.sbd\Ordner-10.sbd\Ordner-11.sbd\Ordner-12.msf

i.e. ".msf" file becomes ;
> C:\Documents and Settings
>    \<MS_Win_user_ID>
>     \Application Data
>      \Thunderbird
>       \Profiles
>        \<Random_String>.<Profile_Name>
>         \ImapMail
>          \<IMAP_Server_Name>
>           \INBOX.sbd
>            \Ordner-01.sbd
>             \Ordner-02.sbd
>              \Ordner-03.sbd
>               \Ordner-04.sbd
>                \Ordner-05.sbd
>                 \Ordner-06.sbd
>                  \Ordner-07.sbd
>                   \Ordner-08.sbd
>                    \Ordner-09.sbd
>                     \Ordner-10.sbd
>                      \Ordner-11.sbd
>                       \Ordner-12.msf

Workaround:
Change profile location or "local direcory:" in "Server Settings" of the IMAP account.

Comment 7

[Olaf J. Pauli]

Problem solved.

It would be nice Thunderbird is testing if the "path length limit" is reached. At this time Thunderbird creates an index-file and at the next time the user will get a broken structure because the folder is always created on the IMAP-server.

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> Problem solved.

If here is Customer Support Center, your "incident" of question/help request will be closed as FIXED, when your problem is bypassed by the workaround.
But here is bugzilla.mozilla.org. FXIED at bugzilla.mozilla.org means that real bug(flaw in Tb's code) really exists and the flaw was corrected by patch. So close code can not be FIXED.

As you say, Thunderbird should notify user about "local .msf file creation failure for an IMAP folder due to path length limit". It may be an enhancement request for kinder error message.
Phenomenon/problem of "silent failure" in your case was already reported to Bug 249807, and Bug 249807 is fortunately still open.
So closing as DUP of Bug 249807. 
(Bug 218167 & Bug 220295 were same problem as yours, but they were closed as)
(WORKSFORME according to server side changes which made path length shorter.)

Comment 9

[Olaf J. Pauli]

Yes, you're right. Thanks for the correction. 

Comment 10

[WADA:World Anti-bad-Duping Agency]

Even if "it works for you now by workaround", close code of this bug can not be WORKSFORME because here is bugzille.mozilla.org. WORKSFORME at bugzille.mozilla.org means "real bug(==flaw in code) really existed, but problem didn't occur any more with newer build(i.e. problem is already fixed by unknown patch already.) 
And, problem of "silent failure" still remains, and it should be improved.
Please note again that here is bugzilla.mozilla.org, not "support forum" nor "customer support center" nor "customer claim accepting counter".

Closing as DUP of Bug 249807 again.