Large folder hierarchies don't seem to work correctly via imap. My instance, my Sent mail is organized as follows Sent/<YEAR>/<domain>/<user>. When I unfold Sent, there are folders for 1998, 1999, 2000, and 2001. Each of which has a large number of subfolders. 1998 expands fine, as does 1999. 2000 expands at times, and 2001 never expands. It just acts like Sent/2001 is a folder without sub folders. Seems to work just fine on other hierarchies that are smaller. My Sent heirarchy is quite large.

Reporter what build id are you using? Have you been able to reproduce this with the latest nightlies or 0.9.2? (which is about to be released)

Right now, I'm running 0.9.1. The bug has been there is older version as well. I've tried anything more recent then 0.9.1 yet. This is on Win2k, but I believe it happens on the linux version as well.

Now I'm running the nightly build with 6/27/2001. It does the same thing.

worksforme with 0.9.4 nightl builds from 09/09 on win2K. please reopen if you are still seeing this in current nightl builds (0.9.3 or newer). thanks.

Worksforme using win98 on oct3 0.9.4 branch. Marking verified worksforme.

Its still broken in 0.9.4. We need mighty big heirarchy to make it break. I have 4 folders, one for each of 1998, 1999, 2000, 2001. Each of these in turn, have a great number of subfolders. When I expand out the folder containing 1999-2001, '98 and '99 alway expand properly. 2000 expands sometimes. 2001 never expands (by expands I mean I get a handle to open it to see the subfolders). If I move 1998-2000 to another folder, then 2001 works fine. I can provide test data if it can be kept confidential. This is all the mail I have sent in the last 4 years. I can setup an account on my server with the hierarchy for testing.

Marking these all WORKSFORME sorry about lack of response but were very overloaded here. Only reopen the bug if you can reproduce with the following steps: 1) Download the latest nightly (or 0.9.6 which should be out RSN) 2) Create a new profile 3) test the bug again If it still occurs go ahead and reopen the bug. Again sorry about no response were quite overloaded here and understaffed.

I screwed up sorry for the spam...reopening...Send your hate mail to ksosez@softhome.net

confirming. Reporter has offered to set up a testcase for the developer who'll get this...

I have been dealing with this on several computers with several different builds (1.0, 1.1a, nightly downloaded an hour ago, etc..) - it is rather frustrating; folders with subfolders will appear without the subfolders - workaround I have found is to collapse and expand parent folder - this works all the way up to the very first level (which would be the IMAP account itself), though I have found it sometimes takes a couple tries. Also, this is definitely not limited to deep hierarchies of folders - for example, I have (using Cyrus): public.todo public.todo.done public.todo.on hold And once in a while I will end up with just `public.todo'. I cannot intentionally reproduce this, though it seems to be most problematic with a newly created IMAP account. One thing I was wondering about is whether or not this had anything to do with a conflict between `subscribed' folders and having the show only subscribed folders option un-checked. Is there a way I can stop it from subscribing to ANY folders, ever? Seems like it happens automatically? If so, this might be a good way to test my theory?

Hopefully this is worth something to somebody.

Looks related to 131938 to me.

I have the same problem. I'm using the latest build (20020826). Courier-imap 1.5.3 is my Imap server. What I see is that Mozilla sends the "LIST" request for "INBOX.%". The next step is sending a LIST for "INBOX.%.%". This brings across the first level of sub-folders. Some of the sub-folders are marked with "HasChildren". Even though Mozilla had the list populated prior, the sub-folders are removed from the list. It looks like Mozilla should send a LIST for INBOX.<FOLDER>.% and INBOX.<FOLDER>.%.% for the next level when children are detected. The pattern should continue for all folders with children. I haven't read the RFC to know for sure, but the Imap server is returing that children are present and another request is not being performed. To recreate the problem, create folders that are at least 3 levels deep. i.e. Save - Archive - 2002 2002 will not show up when you first open the mail client. If you collapse Save and open it again, Mozilla sends a LIST request for INBOX.Save.% followed by INBOX.Save.%.% which picks up the sub folders. Hope this helps.

do you still see this problem with a current release? (In reply to comment #12) > Looks related to 131938 to me. I'm inclined to agree this is a dupe of bug 131938, which was fixed by bug 138759 in 2004