Closed Bug 480508 Opened 16 years ago Closed 16 years ago

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

Categories

(MailNews Core :: Networking: IMAP, defect)

1.9.1 Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 472129

People

(Reporter: lrosa, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

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.
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.
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.
Keywords: regression
Component: Folder and Message Lists → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: folders-message-lists → networking.imap
Version: unspecified → 1.9.1 Branch
Luigi can you provide the imap logs please ?
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
Attached file IMAP Log (compressed) (deleted) —
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
.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
(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?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
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/
Attached file IMAP log 2 (deleted) —
Is compressed with RAR to reduce size
(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.
(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 ?
Done. I created bug #481142
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: