183429 - filters automatically disabled while imap folders loading

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[Tim]

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?

Comment 1

[Enrico Horn]

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.

Comment 2

[Tim]

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.

Comment 3

[Ben Hunter]

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.

Comment 4

[George Fairbanks]

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?

Comment 5

[George Fairbanks]

I should mention that I've experienced this on UW imapd and also the CMU cyrus
IMAP server.  

Comment 6

[Derek R. Price]

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.

Comment 7

[Derek R. Price]

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.

Comment 8

[Derek R. Price]

Adding myself to CC list.

Comment 9

[Asa Dotzler [:asa]]

*** Bug 194297 has been marked as a duplicate of this bug. ***

Comment 10

[Asa Dotzler [:asa]]

*** Bug 232077 has been marked as a duplicate of this bug. ***

Comment 11

[Asa Dotzler [:asa]]

this seems like a problem with the account's folders not being found, rather
than a purely filter problem. ->account manager. 

Comment 12

[volesky]

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.

Comment 13

[Gordon Schumacher]

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.

Comment 14

[Derek R. Price]

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.

Comment 15

[Gordon Schumacher]

Agreed, I haven't seen this in quite a while, not since I upgraded past 1.0.2, as I recall.

Comment 16

[Wayne Mery (:wsmwk)]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2

if you still see a problem see to comment 11 and comment 0, and update the bug