User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.168 Chrome/18.0.1025.168 Safari/535.19 Steps to reproduce: I run Ubuntu 12.04 and recently upgraded to Thunderbird 12. When receiving mail I have a large number of message filters that move the mail into various folders. After upgrading, as I receive mail I get messages that the destination folder cannot be found and the filter is disabled. When I go to manage the filters I usually find one filter that has lost the location of the folder (the folder is there and has not been moved). I manually select the folder, re-enable the filter and run the filter and all goes ok. This happened previously when I upgraded from Thunderbird 10->11 (I presume) and hence why I am filing it under migration. The difference is that this time it seems to be a recurring problem. Let me know whatever information I can provide to help reproduce the problem or any steps to perhaps cleanup my profile or data. Actual results: Filter locations seem to be disappearing requiring me to manually select the folder again, re-enable the filter and run it. Expected results: The destination location of the filter should remain in tact and the filters should continue to work.

"actually not found" condition can be emulated by "rename xxx/xxx.msf/xxx.sbd for local mail folder to yyy/yyy.msf/yyy.sbd" and restart of Tb. If move target folder is actually not found, - When "not found" is detected by message filter execution upon POP3 download, - the filter rule is disabled(enable="no") in memory, and enable="no" is saved in msgFilterRules.dat too. Move tartget folder path in msgFilterRules.dat is not changed. - When "not found" is detected by "Run Filters on Folder", - the filter rule is disabled(enable="no") in memory. but enable="no" is not saved in msgFilterRules.dat. Move tartget folder path in msgFilterRules.dat is not changed. In any case, the filter rule is shown as disabled(enabled box is unchecked) by message filter UI. When the rule is edited, move target folder path is shown as blank, and "save without selecting folder location again" is impossible because Tb rejects to save. If "Cancel" is requested, folder path in msgFilterRules.dat is kept as-is. If move target folder actually exists always and if it's false "folder not found" condition, enabling the rule again may be sufficient because move target folder path in msgFilterRules.dat is unchanged by Tb. Do you see your problem on any mail folder? Or specific mail folder only? What is actual folder name and actual folder/directory path of the maill folder? (see bug 752697 for interesting regression by Tb 12) Is there any Error Console message relevant to your problem? Similar phenomenon(I think same) is reported to Bug 751562. In that bug, bug opener says auto-compact is not relevant to problem. Can you surely rule out "interfere by auto-compact" from your case? (if auto-compact is enabled, set mail.purge.ask=true and restart Tb. when prompt before auto-compact is shown, reply Cancel or OK.) > recently upgraded to Thunderbird 12 How did you upgrade? New install of Tb 12.0.1? Or software update by Tb?

WADA - Many thanks for explaining the behavior and linking to a couple of other issues. It will probably be the weekend before I can test and play with things. What appears to be happening is that there is one folder that is failing (I forget which one but will confirm later) and report back. What seems interesting is that other subfolders are affected after the initial one based on whatever is coming in the Inbox. So it appears - but again I need to confirm - that any of the subfolders after the initial fail also are getting disabled in memory (and possibly written out). Now that I have a better understanding of how things are working I can better troubleshoot and give more information. Peace - Anthony The upgrade was the Ubuntu package upgrade to 12.0.1 so it was a software update. I've used tb for quite a while.

Dupe of bug 714364 or bug 751562?

(In reply to :aceman from comment #3) I think this bug report is for same problem as bug 751562, but that report started with Tb 12.0.0 then slightly confusing, and is slightly messy already by comments for problem analys and comments to rule out possible causes/problems. Bug 714364 is initially reported for Sm 2.6. If same problem/regression as Tb 12, I believe that bug should start from Smb 2.9.0/2.9.1.

Anthony, what is the language of the user interface of your Thunderbird? Do you use a version other than English?

@aceman - I am using English, although I do have an input option for a Spanish keyboard and also Dvorak. Just to update the behavior that I am seeing, with a fresh start of tb one of the filters loses its value in memory and then others folders in that same branch of folders are disabled as they arrive in the Inbox. To remedy things, I can do to any of the disabled filters and the destination folder is empty. Then I re-able the filter and run it. After that, I can go to any of the other filters and simply re-able them and run the filter since they do not lose the data. My guess would be that there is an array that is off or something. I'm finishing off an academic year as a teacher so I'm tied up grading; however, I'll continue to provide more details as I'm able. Peace - Anthony

(In reply to Anthony Borrow from comment #6) > To remedy things, I can do to any of the > disabled filters and the destination folder is empty. Then I re-able the > filter and run it. How do you fix the destination folder? Do you need to select it anew? Or you just enable the filter and it magically works for the destination folder that was there before? >After that, I can go to any of the other filters and > simply re-able them and run the filter since they do not lose the data. So in other filters the destination folder is not empty? But above you said you go to any disabled filter and the folder is empty. I do not understand this part. Also I think you haven't said if there is anything interesting in the Error console.

Thanks for the prompt followup and my apologies for not being clear. So to "remedy things", I go to Tools -> Message filters and scroll down a rather long list of filters and see which ones are missing the enabled check (normally I have them all enabled; however, with the bug several can become disabled when I startup tb). I believe that regardless of which disabled filter I pick to edit, the first one will have lost the destination folder. So to fix it I edit the filter and reselect the destination folder, re-enable the filter and run it. Now for all of the other disabled filters, if I were to try and edit them their destination folder is already there so it is not necessary to edit them. So rather than editing them, I just re-enable them and run them. In terms of what happens at startup, I will get an error that a message cannot be moved because of the missing destination. I have several filters setup to sort out all of the posts made on the moodle.org forums. Several of the filters get disabled depending on which filters tried to run. For example, if there is an email regarding Moodle themes that will be the first filter that fails to run and it is thus disabled. Then I may receive an email regarding Moodle quizzes and it fails and is thus disabled. In the end I can have 5-10 filters disabled when I start tb. If I keep it running, after reabling filters then I do not have any trouble with new arriving mails related to those filters (themes, quizzes, etc.) I would be happy to upload my filter information if there is a convenient way to do so. As for the error console - I'm not sure if related but here is one error that I noticed: Timestamp: 05/28/2012 08:26:49 AM Error: An error occurred executing the cmd_getNewMessages command: [Exception... "Component returned failure code: 0x8055000a [nsIMsgIncomingServer.getNewMessages]" nsresult: "0x8055000a (<unknown>)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: GetNewMsgs :: line 2453" data: no] Source File: chrome://global/content/globalOverlay.js Line: 100

If fixing any filter makes the destination folders appear in all the other disabled filters, that is very interesting. It looks like the first operation fixes some connection bit (inside TB/database) and then other folders are resolved correctly.

Just another note about the behavior I am seeing. It appears that the filter locations are not being loaded in memory or before the processing of the newly arriving messages. I do not need to provide the location of the folder. If I simply edit the filter and then cancel somehow that process then loads all of the locations. If I go back in and edit the same filter I can then see the destination folder location whereas during the first edit the destination was blank. I'm going to try doing this after the first error to prevent so many other folders from being disabled. I hope this helps track down what is happening. If there are other steps you would like me to take to help narrow things down just let me know. Peace - Anthony

This looks like bug 751562. Please reopen if you still see it after upgrading to TB14.