GNOME Bugzilla – Bug 444503
svn build At revision 33660 filters no longer being applied to Exchange incoming mail
Last modified: 2013-09-13 05:07:20 UTC
Please describe the problem: At revision 33658 incoming mail is not being filtered. None of my filters are working as mail comes in. Selecting mail after it has arrived and applying filters works. Steps to reproduce: 1. svn update to 2. At revision 33658. 3. watch as email comes in and filters are ignored Actual results: mail is not filtered Expected results: mail to be filtered as it arrives Does this happen every time? yes Other information: At revision 33658.
cannot reproduce this here, running an svn checkout from a few hours ago.
1) rm -rf'd my entire evolution trunk and re-checked out -> At revision 33660. 2) ./autogen.sh --prefix=/usr --enable-nntp=yes --enable-imap4=yes --enable-cairo-calendar=yes --enable-mono=yes --enable-exchange=yes --enable-plugins=all --with-openldap=yes --with-e2k-debug 3) !!! Discovered that current svn trunk does not install evolution executable as evolution-2.12 but only as evolution !!! so invoking evolution-2.12 started old executable 4) invoked evolution 5) Filters still not affecting incoming emails. 6) ln -s evolution-2.12 evolution 7) filters still not affecting incoming emails 8) manually applying filters <CTRL-Y>, works
just realized that this may pertain solely to inbox associated with an MS Exchange account.
*** Bug 447977 has been marked as a duplicate of this bug. ***
If I, $ gconftool-2 --recursive-unset /apps/evolution $ rm -rf .evolution and restart evolution, and configure it for an Exchange account, filter new messages, filter inbox only, etc, on the initial startup junk filtering and any filters that I add get applied to incoming exchange mail. EDS camel/camel-folder.c line 1818 causes a filter driver to be created which causes filters to be applied to incoming mail. Upon shutdown and restart, no filters are applied to incoming exchange mail because EDS camel-folder.c line 1818 does not cause a filter driver to be created because the folder flags change. camel folder flags on initial startup and configuration = 71 camel folder flags on subsequent startups = 3 Why????? How do I remedy this? Can someone point me to the file/lines where folder_flags are set? Second startup: freeze(0x8688700 'personal/Inbox') = 1 folder_changed(0x8688700:'personal/Inbox', 0x87ff268), frozen=1 added 1 removed 0 changed 0 recent 1 filter 1 thaw(0x8688700 'personal/Inbox') = 0 folder_changed(0x8688700:'personal/Inbox', 0x86a1618), frozen=0 added 1 removed 0 changed 0 recent 1 filter 1 folder->folder_flags=[3] (folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT| CAMEL_FOLDER_FILTER_JUNK)=[0] p->uid_filter->len=[1] fff Initial startup with account creation: content mime-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed < b1837b90 > camel_junk_plugin_check_junk em_junk_sa_check_junk junk filter => clean thaw(0x86b3ce0 'personal/Inbox') = 0 folder_changed(0x86b3ce0:'personal/Inbox', 0x8713630), frozen=0 added 640 removed 0 changed 0 recent 640 filter 0 folder->folder_flags=[71] (folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT| CAMEL_FOLDER_FILTER_JUNK)=[68] p->uid_filter->len=[0] freeze(0x86b3ce0 'personal/Inbox') = 1 folder_changed(0x86b3ce0:'personal/Inbox', 0x87662c8), frozen=1 added 1 removed 0 changed 0 recent 1 filter 1 thaw(0x86b3ce0 'personal/Inbox') = 0 folder_changed(0x86b3ce0:'personal/Inbox', 0x86a4308), frozen=0 added 1 removed 0 changed 0 recent 1 filter 1 folder->folder_flags=[71] (folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT| CAMEL_FOLDER_FILTER_JUNK)=[68] p->uid_filter->len=[1] * launching filter thread 1 new mail, 0 junk and 0 not junk freeze(0x86b3ce0 'personal/Inbox') = 1 freeze(0x86b3ce0 'personal/Inbox') = 2 thaw(0x86b3ce0 'personal/Inbox') = 1 Thread b1837b90 > CamelFolder:get_message('personal/Inbox', '000003be8c2c') = class: CamelMimeMessage mime-type: text/plain; charset=us-ascii content class: CamelDataWrapper content mime-type: text/plain; charset=us-ascii < b1837b90 > camel_junk_plugin_check_junk em_junk_sa_check_junk junk filter => clean thaw(0x86b3ce0 'personal/Inbox') = 0 folder_changed(0x86b3ce0:'personal/Inbox', 0x8697378), frozen=0 added 1 removed 0 changed 0 recent 1 filter 0 folder->folder_flags=[71] (folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT| CAMEL_FOLDER_FILTER_JUNK)=[68] p->uid_filter->len=[0] freeze(0x86b3ce0 'personal/Inbox') = 1 folder_changed(0x86b3ce0:'personal/Inbox', 0x8378648), frozen=1 added 1 removed 0 changed 0 recent 1 filter 1 thaw(0x86b3ce0 'personal/Inbox') = 0 folder_changed(0x86b3ce0:'personal/Inbox', 0x882b4a0), frozen=0 added 1 removed 0 changed 0 recent 1 filter 1 folder->folder_flags=[71] (folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT| CAMEL_FOLDER_FILTER_JUNK)=[68] p->uid_filter->len=[1] * launching filter thread 1 new mail, 0 junk and 0 not junk freeze(0x86b3ce0 'personal/Inbox') = 1 freeze(0x86b3ce0 'personal/Inbox') = 2 thaw(0x86b3ce0 'personal/Inbox') = 1 Thread b082ab90 > CamelFolder:get_message('personal/Inbox', '000003be8c2e') = class: CamelMimeMessage mime-type: text/plain; charset=us-ascii content class: CamelDataWrapper content mime-type: text/plain; charset=us-ascii < b082ab90 > camel_junk_plugin_check_junk em_junk_sa_check_junk junk filter => clean thaw(0x86b3ce0 'personal/Inbox') = 0 folder_changed(0x86b3ce0:'personal/Inbox', 0x87486e8), frozen=0 added 1 removed 0 changed 0 recent 1 filter 0 folder->folder_flags=[71] (folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT| CAMEL_FOLDER_FILTER_JUNK)=[68] p->uid_filter->len=[0] fff
current build info.... rthompso@jhereg: ~/src/svn/evolution-data-server$ svn info Path: . URL: http://svn.gnome.org/svn/evolution-data-server/trunk Repository Root: http://svn.gnome.org/svn/evolution-data-server Repository UUID: d0434b6f-c725-0410-8785-fd8a057797ef Revision: 7866 Node Kind: directory Schedule: normal Last Changed Author: pchen Last Changed Rev: 7866 Last Changed Date: 2007-07-09 06:46:09 -0400 (Mon, 09 Jul 2007) rthompso@jhereg: ~/src/svn/evolution-data-server$ cd ../evolution rthompso@jhereg: ~/src/svn/evolution$ svn info Path: . URL: http://svn.gnome.org/svn/evolution/trunk Repository Root: http://svn.gnome.org/svn/evolution Repository UUID: 9792ae6b-c725-0410-a7bc-87ac6a6ec1ac Revision: 33789 Node Kind: directory Schedule: normal Last Changed Author: sragavan Last Changed Rev: 33789 Last Changed Date: 2007-07-09 07:28:57 -0400 (Mon, 09 Jul 2007) rthompso@jhereg: ~/src/svn/evolution$ cd ../evolution-exchange/ rthompso@jhereg: ~/src/svn/evolution-exchange$ svn info Path: . URL: http://svn.gnome.org/svn/evolution-exchange/trunk Repository Root: http://svn.gnome.org/svn/evolution-exchange Repository UUID: cbd800bf-df25-0410-b17b-96628719a9b0 Revision: 1386 Node Kind: directory Schedule: normal Last Changed Author: ankitp Last Changed Rev: 1386 Last Changed Date: 2007-07-06 07:29:27 -0400 (Fri, 06 Jul 2007)
updated evo et al today... removal of evolution configuration settings is not required. If I re-build evolution, on the first startup folder->folder_flags=[71], on subsequent startups folder->folder_flags=[3]
Could someone verify for me what folder->folder_flags *should* be on 'personal/Inbox' for Exchange OWA if I DO want to have filters applied and the junk filter applied. I continue to get folder->folder_flags=[3] which equates to 0 when masked with (CAMEL_FOLDER_FILTER_RECENT|CAMEL_FOLDER_FILTER_JUNK)
rthompso@jhereg: ~/src/svn/evolution-data-server$ svn info Path: . URL: http://svn.gnome.org/svn/evolution-data-server/trunk Repository Root: http://svn.gnome.org/svn/evolution-data-server Repository UUID: d0434b6f-c725-0410-8785-fd8a057797ef Revision: 8031 Node Kind: directory Schedule: normal Last Changed Author: vvaradan Last Changed Rev: 8031 Last Changed Date: 2007-09-03 03:44:42 -0400 (Mon, 03 Sep 2007) I still have this problem -- Exchange INBOX always returns folder->folder_flags = 3, which causes if ((folder->folder_flags & (CAMEL_FOLDER_FILTER_RECENT|CAMEL_FOLDER_FILTER_JUNK)) && p->uid_filter->len > 0) to fail, which causes NO filter to be created and applied. Can someone help me trace down the cause of this. I am running current svn head of eds, evo. and evo-exch... How/where is folder->folder_flags determined/stored at?
well -- i had hoped that this was an issue with some configuration specific to my machine. But I guess not. Different PC, new install of Gentoo ( vs UBUNTU ) Build from svn head 20070917. Same initial results -- filters are not being applied to OWA incoming mail. (I have not added in the debug statements to see if the folder_flags are coming up the same ).
Created attachment 99190 [details] [review] Patch for bug 444503 in evolution-exchange The optimization of "not fetching messages if folder summary is available" should be done after storing the filter flags. The attached patch would fix those issues.
Committed to trunk http://svn.gnome.org/viewvc/evolution-exchange?view=revision&revision=1502
*** Bug 368417 has been marked as a duplicate of this bug. ***
*** Bug 490347 has been marked as a duplicate of this bug. ***
There's a race condition or some other nasty getting exercised in this code. When I patched 2.12.1 with the patch from comment #11 it applied cleanly, but now I get random evolution-exchange crashes when new mail arrives, and evo complains "Lost connection to Evolution Exchange backend process" when switching folders. Doesn't happen all the time, but often enough that I have to restart all of Evo's components 5 to 10 times daily. This exact behavior was occurring in 2.10 but I didn't figure out that it happened only when checking for new mail and filtering, so I hadn't yet reported it as a bug since I couldn't isolate it. Now I can -- 2.12.1 without the patch does not crash at all, runs for days. 2.12.1 with the patch does crash, 5-10 times daily. Note that selecting messages in the index and using CTRL-Y does not trigger crashes. No recovery seems possible without restarting evolution completely.
Anyone else finding the same problem? Reid can you confirm it? What the optimization does? It doesn't fetch the folder summary for folders on starting evolution. Only when you ask the server to fetch it for you, it fetches new mail. What the patch does? It just stores the filter and junk flags. Olegario Craig, Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
It will be next week before I can answer this. I was out of the office Mon-Wed of this week and on Holiday Thu-Fri. Will advise if I get the same issues.
OK -- i'm getting crashes in /usr/libexec/evolution-exchange-storage, tickets 499773 and 499720 and 499718 contain backtraces. Multiple crashes. So far signal handler is called in 3 different places. Not sure if this is related to this fix or not.
(In reply to comment #16) > Anyone else finding the same problem? Reid can you confirm it? Looks like Reid may have found something, based on comment #18 -- I hope so, because I won't be able to dig into this until (likely) 12/5 or after. (Work is flying me cross-country to fix _our_ software. Presumptuous of them, cutting into my Evo bughunting time. :-) > What the optimization does? > It doesn't fetch the folder summary for folders on starting evolution. Only > when you ask the server to fetch it for you, it fetches new mail. > > What the patch does? > It just stores the filter and junk flags. Right -- I don't think code in the patch itself is at fault, I just think that the patch is catalyzing execution of something dodgy that wouldn't otherwise be hit in the same way, and I suspect a race condition purely because of how the bug manifests - not hard-reproducible, seems more likely to occur when there's multiple new emails that trigger filters, &etc.. > > Olegario Craig, > Without a stack trace from the crash it's very hard to determine what caused > it. Can you get us a stack trace? Please see > http://live.gnome.org/GettingTraces for more information on how to do so. Will do as soon as I can. Thanks for looking at this!
I was tracking the progress of this bug in the wrong thread http://bugzilla.gnome.org/show_bug.cgi?id=272611. I was finally able to get evolution compiled from CVS last week, and just wanted to add that the filters are now applied properly (that is as they come in). On a possibly unrelated note, I leave my PC on 24/7 at work and when I came in this morning the evolution window was nowhere to be found, but the process was using nearly 100% of one of my two CPUs. I just thought I'd mention it here just in case it was related. --Stephen
I'm on Fedora 8. Both the updates and updates-testing RPMs for evolution started exhibiting this behavior yesterday and I couldn't get them to behave. They're around version 2.12.2 give or take a minor rev in one of the components. I usually export all email out of my inbox and pipe it to procmail/mh-e/xemacs, leaving the calendar messages behind (my exchange server does not allow imap, or I would fetchmail directly). When the problem started I had one (and the same) appointment request in both exchange's in evolution's personal/inbox and the filter wouldn't be applied to new messages. As soon as I handled that appointment, thus clearing my inbox, the filters restarted being applied and email started flowin into mh-e normally. Not sure if relevant or not.
The regressions mentioned in this bug have been fixed in http://bugzilla.gnome.org/show_bug.cgi?id=420503 It'll be committed soon to trunk. I tested it and it does filter sanely without any regressions.
I have this bug still in Fedora 12 using Evolution 2.28.2 Any updates on this bug?
I have this bug in Ubuntu natty with Evolution 2.32.2 How can I help with debuggin fixing this issue?
I have this bug still in CentOS 6.3 using Evolution 2.28.3 It seems like a fix was produced in 2008, but I guess it never made it into the main build?
This bug report was fixed by comment 12. In case the problem still happens with Evolution version 3.6 or 3.4: Feel free to file a new bug report and mention the Exchange package that you use (see http://library.gnome.org/users/evolution/3.6/exchange-connectors-overview.html ). To provide debug information in that new report, see http://projects.gnome.org/evolution/bugs.shtml > Discover What Causes the Bug > Microsoft Exchange accounts.