Bug 481121
| Summary: | "Summary and folder mismatch, even after a sync" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | luca, mbarnes, mcrha, mike, scp.stjohn, tomc |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-10-23 20:29:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I don't have this problem, not everyday, it occurs rarely: Are you using imap, pop, excahge or something else? Are you using vfolders? How many account do you have? thanks Luca I have a local Inbox with a POP account, and I also have a set of IMAP folder (which are not affected by this problem). I do have vfolders defined but I am not using them. There is an upstream effort to fix this issue, see [1] [1] http://bugzilla.gnome.org/show_bug.cgi?id=550414 This seems to be fixed via upstream. Can you verify it is indeed fixed and/or if you are having this problem still? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers I am having the same problem with Evolution. Google search reveals that this has occured with other users many times in the past and has supposedly been resolved. It started happening a few days ago after I was experimenting with VNC and checking my email in the VNC shell. It may be just a coincidence or it may be related. I no longer use VNC - favouring freeNXserver instead - but the problem persists. Deleting .evolution/mail/local/Inbox.ibex.index or Inbox.cmeta appears to temporarily resolve the problem - but it soon reoccurs. Mail already received and read, or mail filtered to Junk, etc - reappears in the Inbox with an unread status. I use POP to download email from my mail server. I am using Spamassassin both on the mail server and locally with Evolution. I also use Bogofilter. This would seem to be a problem of one index file getting corrupted - but which one? I've tested this again.
Step 1. Delete .evolution/mail/local/Inbox.ibex.index and
Inbox.cmeta appears to resolve the problem.
Step 2. Use Evolution in a VNC or freeNXserver session and the problem reoccurs each time mail is fetched from the server:
>>Error while Storing folder 'Inbox'.
Summary and folder mismatch, even after a sync
<<
Step 3. Disconnect or terminate VNC or nxserver shell and use Evolution in a normal session to download mail and the problem persists.
So it seems that this problem - at least in my case - is related to using Evolution in a VNC or NXserver shell. I can only guess that this may have something to do with the way in which Evolution writes its indexes. (Perhaps it has something to do with date/time?). When these errors occur - mail that has previously be deleted or marked as junk - or manually filtered to other folders - will reappear in the In folder marked as unread.
How reproducible:
Happens at least every day.
This bug report seems to be turning into a soliloquy blog. No response out there. My problem with Evolution is getting worse and I an no longer sure that it is solely related to vncserver or nxserver use. For the record, I am currently running Fedora 10 with Gnome 2.24.3 and Evolution 2.24.5. I deleted the contents of my junk folder while in a remote nxserver session. Following that I now cannot empty the Trash folder - whether I am in an nxserver session or not. "Error while storing folder'.#evolution/Junk.'" If I quit Evolution and restart it - the deleted mail reappears in the Junk folder. Would really appreciate some advice. (In reply to comment #7) > This bug report seems to be turning into a soliloquy blog. No response out > there. Anything like the above really doesn't help... Not mentioning the weekend... About the fix, there had been some code trying to fix the issue on the fly, but upstream decided to remove it, for some issue it was causing. I've no exact information what was that about, I'm sorry. Did you read [1] please? There is no better way at the moment. [1] http://www.go-evolution.org/FAQ#Why_do_I_get_an_error_.22Summary_and_folder_mismatch.2C_even_after_a_sync.22.3F Yes - I had tried the recommendations in that link earlier, thanks. That did not resolve the issue. I should have read the link in Comment #3 above carefully: [1] http://bugzilla.gnome.org/show_bug.cgi?id=550414 Deleting folders.db in .evolution/mail/accounts did the trick, finally. Now I do not get any sync errors either in a normal or a nxserver session. I was also able to empty the Trash following this procedure. I guess it is possible that disconnecting from a VNC session before Evolution completed updating its index may have corrupted the tables? (In reply to comment #9) > Deleting folders.db in .evolution/mail/accounts did the trick, finally. Ouch, right, I forgot of that, it's a new .ev-summary equivalent. > I guess it is possible that disconnecting from a VNC session before Evolution > completed updating its index may have corrupted the tables? Sounds very likely to me. Is this issue still present in Fedora 12? Haven't seen it. Closing for now. This is one of those bugs that's been haunting us on and off for years, so we'll see if it crops up again. |
Description of problem: Quite frequently I get this error dialog while fetching mail: ==> Error while Storing folder 'Inbox'. Summary and folder mismatch, even after a sync <== ('Inbox' is a local folder.) I am using spamassassin for junk mail detection in case that's relevant. Version-Release number of selected component (if applicable): evolution-2.24.3-1.fc10.x86_64 How reproducible: Happens at least every day. Steps to Reproduce: 1.Fetch mail. Additional info: Didn't happen until I updated to the updates-testing package.