480508 - Folder of 3rd level and deeper created with other clients are not seen by TB on IMAP accounts

Status: RESOLVED DUPLICATE of bug 472129

(MailNews Core :: Networking: IMAP, defect)

Description

[Luigi Rosa]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Build Identifier: 3.0b2

Folder deeper than third level are not visible on TB if the folder is created by another mail client (even anotehr Thunderbird) on IMAP accounts. If the folder is created by TB 3.0b2 is visible on the folder tree both in TB 3.0b2 and other clients. The opposite (folders created with other clients) does not happen.

This happens both with Dovecot and Merak Ice Warp servers.

Reproducible: Always

Steps to Reproduce:
1.Create a third level folder in an IMAP account with a client different from TB 3.0b3
2.Start TB 3.0b3
3.Verify that the folder is not displayed in the folder tree

Actual Results:  
The 3rd level folder are not displayed

Expected Results:  
Every subscribed IMAP folder should be displayed on IMAP folder tree regardless of level

If you right-click on account name and select "Subscribe..." the folder is visible, the subscribe flag is activated, but the folder is not displayed on folder tree.

Comment 1

[Ludovic Hirlimann [:Usul]]

Reporter can you follow the instructions at https://wiki.mozilla.org/MailNews:Logging and log imap to see what's going on when you subscribe to a deep folder. And attach the log to this bug. Thanks.

Comment 2

[Luigi Rosa]

More: 
1. Create a 3rd level folder with 3.0b2
2. Delete the same folder with another IMAP client
3. Go back in 3.0b2
4. Close parent folder and reopen it (in TB 2.0 this causes a refresh of the
subfolders)
5. The folder is still displayed, clicking on it causes a "non existent folder"
error by the IMAP server

Of course the same operations in TB 2.0 do not result in a bug, because TB 2.0
refreshes the subfolders.

Comment 3

[Ludovic Hirlimann [:Usul]]

Luigi can you provide the imap logs please ?

Comment 4

[Luigi Rosa]

Ludovic,
I created this tree with TB 2.0:

tb30b2 level1
\-tb30b2 level2 a
  \- tb30b2 level3 a
   - tb30b2 level3 b
 -tb30b2 level2 b
 -tb30b2 level2 c

Then I started 3.0b2 and tried to access tb30b2 level2 a without success; then I created "newfolder 1" under "tb30b2 level2 c"

I attaching the log of this operations

Comment 5

[Luigi Rosa]

Attachment: IMAP Log (compressed)

Comment 6

[Ludovic Hirlimann [:Usul]]

0[1727140]: creating protocol instance to play queued url:imap://lrosa@62.123.164.113:143/listfolder>.HT list.magliette.zz
0[1727140]: failed creating protocol instance to play queued url:imap://lrosa@62.123.164.113:143/listfolder>.HT list.magliette.zz

Comment 7

[Luigi Rosa]

.HT list.magliette.zz no longer exists, I deleted it using TB 2.0 (.HT list.magliette still exists)

.HT list.magliette.zz remained in the offline cache of TB 3.0

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Folder deeper than third level are not visible on TB
> if the folder is created by another mail client

(1) Intial greeting contains CAPABILITY list
> LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
(2) CAPABILITY list in authenticate response
> LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND
>  UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE
>  QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
(3) "capability" command is not issued because of (1), and (2) is ignored.
    This is problem of Bug 470650.
    
Tb issues list "%" and list "%.%" only. This may be reason of "no third level folder". Due to loss of LIST-EXTENDED, CHILDREN etc.?

(In reply to comment #4)
> Then I started 3.0b2 and tried to access tb30b2 level2 a without success;

SELECT of "tb30b2 level1.tb30b2 level2 a" is normally done.
>(log for "SELECT")
> 2 select "tb30b2 level1.tb30b2 level2 a"
> 2 OK [READ-WRITE] Select completed.
What do you mean by "without success"? Subfolders("... level3 ...") under "tb30b2 level1.tb30b2 level2 a" are not displayed?

Comment 9

[Luigi Rosa]

Excatly: folders are not displayed and there is no (+) sign othe left of parent folder in the folder list indicating that the folder has childs.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Bug 472129 was FIXED on 2009-02-27. Luigi Rosa, check with latest-trunk, before Bug 470650 will be fixed, please.
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

Comment 12

[Luigi Rosa]

Attachment: IMAP log 2

Is compressed with RAR to reduce size

Comment 13

[Luigi Rosa]

(see attached IMAP.RAR log file)

I have good news and bad news.

Good news is that the above bug is gone in the nightly build you pointed me to.

Bad news is that I discovered a bug present in TB 3 as well in TB 2. The bug is related to renaming of IMAP folders.

I created this subtree:

shredder
 \ -sh level1 a
   \ -sh level2 11
     -sh level2 2
     -sh level2 zz
   -sh level1 b
   -sh level1 c


Renaming "sh level2 zz" to "sh level2 3" in TB 2.0 causes displaying BOTH "sh level2 zz" and "sh level2 3" in Shredder.

This bug hapens in TB 2.0 when I rename "sh level2 11" in Shredder.

Comment 14

[Ludovic Hirlimann [:Usul]]

(In reply to comment #13)
> (see attached IMAP.RAR log file)
> 
> I have good news and bad news.
> 
> Good news is that the above bug is gone in the nightly build you pointed me to.
> 
> Bad news is that I discovered a bug present in TB 3 as well in TB 2. The bug is
> related to renaming of IMAP folders.
> 
> I created this subtree:
> 
> shredder
>  \ -sh level1 a
>    \ -sh level2 11
>      -sh level2 2
>      -sh level2 zz
>    -sh level1 b
>    -sh level1 c
> 
> 
> Renaming "sh level2 zz" to "sh level2 3" in TB 2.0 causes displaying BOTH "sh
> level2 zz" and "sh level2 3" in Shredder.
> 
> This bug hapens in TB 2.0 when I rename "sh level2 11" in Shredder.

Can you open a new bug for that - reproduce and attach the imap log file generated by shredder ?

Comment 15

[Luigi Rosa]

Done. I created bug #481142