User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1; MultiZilla v1.1.32 final) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1; MultiZilla v1.1.32 final) Gecko/20021130 Having many IMAP folders, and many filters on those folders, when I open Mozilla mail, it seems to take the imap server some time to regenerate (?) the folders in the tree pane... meanwhile error messages start popping up saying those folders do not exist, and so the filter associated with them will be disabled. The solution to this may be more IMAP related than filter related. I'm not sure. Reproducible: Always Steps to Reproduce: 1. Create a lot of IMAP folders, and subfolders 2. Create a bunch of filters on those folders 3. Open mozilla mail... Actual Results: Error messages pop up saying the folders do not exist and that the filter will be disabled. Expected Results: Waited for the imap folders to be discovered?
I have the problem that this doesnt happen at startup time instead when leaving mozilla running for some. But I have set my imap account to check for mail every ten minutes so this might happen mozilla checks for new mail. The problem is that not all subfolders arent available when this happens and the list of subfolders that still exist isnt the same every time this occurs. BTW this affects the imap folder list shown when trying to create filters that move a mail and moving the mail manually to another folder.
After some thinking, it seems to me that the easiest way to fix the functionality of the filters if the filters don't know reliably what IMAP folders exist sometimes when they run, is simply to assume that all the defined folders exist until it is discovered that one does not. In other words, attempt to filter blindly to whatever folder is defined in the filter, but if the imap server reports moving the message fails, then pop up the error message and disable the filter.
I experence the same behavor. Seems Mail starts applying the filters before all (subscribed) imap folders are loaded. Run into this problem on folders in the "third level" under the inbox: Inbox ->Folder1 | ->Folder1.2 | ->Folder1.2.1 | ->Folder1.2.2 (etc) Folders level 1, 1.2 are ok. But filters on folder level 1.2.x are failing on startup ("folder doen't exist"). I have to manually open the subfolders on 1.2.x before filter will process this folders. All(!!) folders are on a cyrus imap server and subscribed. Folders contain many mails. Client: Mozilla 1.2.1, experienced on Win2000/Win98 and Linux. Seems not to be OS specific.
I'm experiencing this problem too. What appears to be happening is that when the mail app is launched only the first couple levels of the folder hierarchy are loaded/refreshed. The specific problem I have is that the folder inbox.cmu.research.bill.fluid does not initially appear. I can force it to appear by contracting then expanding the "research" folder, then contracting then expanding the "bill" folder. When I launch the mail app and have not done this manual intervention, messages that are destined for the "fluid" folder cause the error message noted above and the filter is disabled. It's my understanding that the IMAP protocol doesn't have a command like "get all the mailboxes" -- instead the client has to iterate to get all the children. If this is true, it may have been a deliberate decision to only recurse N levels into the folder hierarchy. Fixing this bug probably means revising this decision. Can someone who knows a bit more inform me? I'm willing to try to fix this bug. Can someone point me at some relevant parts of the code?
I should mention that I've experienced this on UW imapd and also the CMU cyrus IMAP server.
I'm experiencing this with Courier-IMAPD 3.0.3. It looks like a sub-folder refresh issue to me too. My usual work-around is to open and close folders containing sub-folders and then re-run and re-enable any filters that just turned off, but that's a pain to do with every restart. The blind move suggestion from Tim sounds reasonable to me. The alternative would seem to be a recursive search of the folder list to search for subfolders until all the terminal nodes are reached, perhaps in conjunction with folder-list caching.
I think this is related to bug #232077, which I also experience with Moz 1.6 & Courier-IMAPD 3.0.3. My workaround, opening each folder which I would like the mail filters to find, also causes the subfolders to show up in the move-to menus. I expect the folder list search on startup, perhaps with caching from previous runs, would need to be used to fix the move-to menu issues.
Adding myself to CC list.
*** Bug 194297 has been marked as a duplicate of this bug. ***
*** Bug 232077 has been marked as a duplicate of this bug. ***
this seems like a problem with the account's folders not being found, rather than a purely filter problem. ->account manager.
Assignee: naving → sspitzer
Status: UNCONFIRMED → NEW
Component: Filters → Account Manager
Ever confirmed: true
QA Contact: laurel
I have experienced this issue randomly. Notably, I haven't seen it in the past, but recently I've changed to point my mail client (Thunderbird 0.6 (20040502) to a differnet version of IMAP server. Before, I was using an old version of UW IMAP (a build from 1998), and we recently compiled and are using a 2004 version (IMAP4rev1 2004.350). I only have about 3 filters, and about 30 folders (the three filters filter mail to 3 separate folders) and I randomly get this message upon startup: "The folder <foldername> could not be found, so filter(s) associated with this folder will be disabled. Verify that the folder exists, and that filters point to a valid destination folder." I never had this issue with the old UW IMAP and Thunderbird .6 -- this is a new issue since I've gone to the newer version of UW IMAP. Hope that helps.
Bug 239937 is also a duplicate, BTW... can someone fix that? I see this on my setup; I'm running Dovecot on my server. I've actually only got two folders deep, but I have many, many messages in some of them - and I'm frequently running over a slow connection. Both of those pieces of information might be relevant.
I don't recall when this problem disappeared for me, but I haven't encountered it or bug #232077 in some time. This issue can probably be closed.
Agreed, I haven't seen this in quite a while, not since I upgraded past 1.0.2, as I recall.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060516 SeaMonkey/1.0.2 if you still see a problem see to comment 11 and comment 0, and update the bug
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
Version: Trunk → 1.4 Branch
You need to log in before you can comment on or make changes to this bug.