GNOME Bugzilla – Bug 303225
Left pane is not updated with maildir
Last modified: 2005-07-04 09:40:24 UTC
Please describe the problem: The left pane is not updated when you are reading/deleting msgs, showing right number of emails unread only when evolution is just laucnhed. Still showing same unread msgs even if you read/delete some. I'm using Maildir format for stocking my local emails. Steps to reproduce: 1. Launch evolution 2. Read mails 3. look at the left pane Actual results: Number of unread messages doesn't change Expected results: Number of unread messages should be update Does this happen every time? yes Other information: using ubuntu packages: ii evolution 2.2.1.1-0ubuntu4 ii evolution-data-server 1.2.1-0ubuntu1 ii evolution-webcal 2.2.0-0ubuntu1 ii libcamel1.2-3 1.2.1-0ubuntu1 ii libebook1.2-3 1.2.1-0ubuntu1 ii libecal1.2-2 1.2.1-0ubuntu1 ii libedata-book1.2-2 1.2.1-0ubuntu1 ii libedata-cal1.2-1 1.2.1-0ubuntu1 ii libedataserver1.2-4 1.2.1-0ubuntu1 ii libedataserverui1.2-4 1.2.1-0ubuntu1
Hi I can confirm this here, this happens only with my maildir folder, the counter on the left pane is updated correctly with my local evolution inbox with the welcome to evolution message.
Created attachment 46216 [details] Here you see in the red box that there are no new messages
By the way, I was able to reproduce this on a Debian and a Gentoo System using Evolution 2.2.1.
*** Bug 305540 has been marked as a duplicate of this bug. ***
See http://bugs.gentoo.org/show_bug.cgi?id=87043 in Gentoo Bugzilla. Also: Only after changing to a folder that hasn't any new mails and then restarting Evolution the new email count dissappears. If you stay in the folder with the new emails and restart, it shows not only the new count, but also just read mails as new again.
I initially saw this problem when upgrading to evolution-2.2.1.1 (as part of gnome-2.10) here, but downgrading to evolution-2.0.4 doesn't solve it. The problem must lie within one of the supporting libraries?
Per advice by dave_largo in #evolution, I tried creating a new test user and ran the evolution wizards as that user. The new setup does not show the above problem, so it is likely an upgrade issue.
While I could get the test account going, I can not seem to get my own account going... I've tried deleting all ~/.gconf* and ~/.evolution files - still no go. There are no error messages in the console.
Now the problem is present on a newly created test account as well... :/
confirming this because of the many people reporting this.
adding migration keyword, as per comment #7
As I said in comment #9, I am no longer sure this is a migration problem :/
Usually problems like this are the backend creating inconsistent uri's and/or not comparing them properly. e.g. adding and/or not ignoring extra /'s, etc. If the uri's used to obtain the same resource are considered different, but they're not, you can end up with different folder objects being accessed by different parts of the code - i.e. things changed in one dont update the other. Actually you may end up with 2 different stores that have their own folder sets. Migration shouldn't affect this anymore since folder uri's are not stored directly in the filter/vfolder files now, unless they coulnd't be resolved to the new uri scheme. But even then this can be fixed by the uri comarison function on the store. If you turn on CAMEL_DEBUG=all I think it might spit enough to resolve this, i.e. are the folder objects returned from get_folder the same physical pointer. May need to add some printfs to session:get_service or use gdb to track this. May need to turn on the debugging inside em-folder-tree-model and/or mail-folder-cache.c too (the #define d(x) ... macros at the top of the file). It shouldn't be a major issue once you find it.
(the uri's are generated from store:get_folder_info, the maildir code is in evolution-data-server/camel/providers/local/*maildir*.[ch] & it subclasses camel-local-store)
Created attachment 47441 [details] [review] fix
I can confirm that the above fix resolves the problem.
I'm seeing this problem with FC4, using stock RPMs for evolution-data-server-1.2.2-3 and evolution-2.2.2-5.
I've filed a bug report with RedHat to get this fix integrated into a Fedora RPM: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162278
Fix committed in 2.3.4.