GNOME Bugzilla – Bug 675287
Spool file account doesn't show messages
Last modified: 2013-02-15 10:11:37 UTC
For an unknown reason, clicking in the local account entry, shows up a warning in yellow background about filtering issue in the INBOX folder for the local account. When I then click on a mail header, I am no able to read the mail. I can't reproduce it but this keep on happening even though I have cleaned up my /var/spool/mail account with mailx (for an unknown reason evolution never removed the entried there even though they were removed in evolution. is it another bug ?)
What account type is this about? If you start Evolution from a terminal and go to that folder, which output do you get?
so this happening every time I receive a new mail in /var/spool/mail/solstice When I open evolution, I get that yellowish banner with the message: "Error while performing operation. Summary and folder mismatch, even after a sync" The list of emails is correct. However, I can't read any of them because clicking on the header does not do anything This is only for the local account. The next time I open evolution and I don't get new mail in local account (/var/spool/mail/solstice), I get no warning AND the list of emails in local account is empty ! In terminal, I got this when I got the yellowish banner: $ LANG=C evolution ** (evolution:12702): CRITICAL **: categories_icon_theme_hack: assertion `filename != NULL && *filename != '\0'' failed (evolution:12702): evolution-network-manager-WARNING **: network_manager_query_state: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (evolution:12702): camel-local-provider-WARNING **: spool summary - not loading anything (evolution:12702): camel-local-provider-WARNING **: The next message didn't start where I expected, building summary from start (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead (evolution:12702): camel-WARNING **: CamelSpoolStore::get_folder_sync() set its GError but then reported success (evolution:12702): camel-WARNING **: Error message was: Summary and folder mismatch, even after a sync (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead Gonna cache uids: 0 (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead Gonna cache uids: 0 (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead Gonna cache uids: 0 (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead (evolution:12702): camel-WARNING **: Error in execution: Failed to retrieve message (evolution:12702): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Error executing filter search: Failed to retrieve message: (junk-test) Gonna cache uids: 0 Gonna cache uids: 0 (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead (evolution:12702): camel-local-provider-WARNING **: Didn't get the next message where I expected (367384) got 0 instead The list of emails is correct. However, I can't read any of them because clicking on the header does not do anything This is only for the local account. The next time I open evolution and I don't get new mail in local account (/var/spool/mail/solstice), I get no warning AND the list of emails in local account is empty ! This is a new bug that began to happen with evolution 3.4.1
Created attachment 213420 [details] example of var/spool/mail file that cause problem I have edited the file to change the email adress I was able to reproduce the problem by mailing root which is forwarded to my account by postfix.
Downstream bug report about the same from 3.6.2: https://bugzilla.redhat.com/show_bug.cgi?id=901942 And I can reproduce it as well, thus confirming.
Hmm, this is interesting. The issue cured itself after restart of evolution (the second or the third), the warning on console is gone, and I can read messages properly now.
The issue consistently persists for me, despite restarts and other changes. I am the submitter of: https://bugzilla.redhat.com/show_bug.cgi?id=901942 If there is any information that I can provide that would be of use, please let me know.
Hrm, I cannot reproduce this anymore, works fine for me now, on newly created accounts. Based on the errors on console, the folder summary is broken for some reason. Please try to go to ~/.local/share/evolution/mail and check subfolders of that folder. You can skip the 'local' and 'trash' folders, those are irrelevant for us. Mine folder has an '@' in its name, and its content is only: folders.db INBOX.cmeta INBOX.ibex.index INBOX.ibex.index.data such folders only index messages from elsewhere. Close evolution, and move such folders away, then run evolution. Evolution will recreate the folder summary, which should make you this working. It'll be good to check what is broken in your folders.db file too, in case the evolution code will be able to fix it on its own, rather than claim only.
Milan: I tried moving those files elsewhere, but the problem persists. I also moved 'vfolder' which was located in ~/.local/share/evolution/mail but that didn't make a difference either.
I confess, I'm getting out of ideas here, the most confusing thing for me is that I also saw those warnings/errors, but I do not anymore. On the other hand, I do get the error with the attached mbox file from comment #3 consistently.
Created attachment 235139 [details] changes in var-spool-mail These are changes in the attached var-spool-mail file which evolution does on its own. It seems to me that by reformatting there one header (folding), and by adding its own header, it also moves the message offset, but doesn't reflect it into the summary properly. I got the summary error as many times as many messages there are, then it stopped claiming and the mbox is shown without errors. Let's see what can be done to avoid this self-breakage.
(In reply to comment #10) > I got the summary error as many times as many messages there are, then > it stopped claiming and the mbox is shown without errors. Oops, not true, it just stopped claiming suddenly for me. Run count has no direct influence on this.
Created attachment 235141 [details] [review] eds patch for evolution-data-server; Got it. Such a stupid bug. The camel_folder_summary_get_array() returns array of summary UIDs in a "random" order (I think they are shuffled by a GHashTable) and as such the order doesn't match order in the file, thus the errors were about "position of message 2 doesn't match position of message 1" which makes sense. When the array is sorted properly, then everything starts working again, regardless the changes in the mbox file evolution will do.
Created commit 70935cf in eds master (3.7.90+) Created commit 7145a1e in eds gnome-3-6 (3.6.4+)
*** Bug 692315 has been marked as a duplicate of this bug. ***
This issue is tracked (and closed) in the Debian BTS under the number 640851 [1]. The patch has been backported and applied to the Debian package `evolution` 3.4.4-3. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640851
(In reply to comment #15) > This issue is tracked (and closed) in the Debian BTS under the number 640851 > [1]. The patch has been backported and applied to the Debian package > `evolution` 3.4.4-3. With that patch applied a new folder showed up in my folders list: somename_tmp. I guess that this is a leftover folder from a failed migration, which is now detected again. > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640851