Could you attach the offending mailbox, .ibex and .ev-summary files?

(if they're not too big or private, or alternatively mail them to
notzed@ximian.com (as a compressed tar file) if you dont want them on
the internet)

I think this is a duplicate somewhere, but i can't find it atm.

The mail box contains a lot of work emails, so I'd have to do
some extensive clean-up before I can send it out to anyone else.

Unfortunately, since I can't expunge, I can't actually perform the 
cleanup.

Anything else I could do?

I'm affected by this bug as well, have been ever since beta 1 (when I
started using evo). I just deleted the .ev-summary file and let evo
rebuild it (which loses read/unread status etc - not a recommended
thing to do!).

I thought this bug was general knowledge as it occures so often,
several times a week is not unheard of, typically on the Inbox which
in my case sees ~100 messages a day. It can and does however occur in
any mailbox.

It's a very irritating bug, as it prevents me from managing my email
in a good fashion.

I just tried deleting the mbox.ev_summary file and it worked like
a charm. It even recovered the read/unread status.
Now I'm able to expunge.

Thanks for the suggestion.

I've just had this pop up on me, too, in my Inbox. I can't get rid of
messages I've moved to other folders. I'm running the "17" version
(according to the splash page), built it from cvs update on Saturday.

Something perhaps related... I've also run out of enough room lately
to do the expunges. So I freed up another 100 meg, and now this
problem popped up. Perhaps allowing my free space to shrink to less
than the size of the mailbox could have been a factor in something
getting corrupted?

*** bug 210405 has been marked as a duplicate of this bug. ***

Well i dont know what to do about this bug.

Never seen it myself, tested a fair bit.

Some fixes recently migrated from the tcp code to the fs stream code
may have changed/fixed this behaviour, if you are actually getting
truncated messages inside the mailbox.

Are any of you guys running SMP kernels?

I dont know what to do about this bug.  I have no plans on changing
any code to fix it atm.

Move it to 1.0.x; if we get any further information we can look at it
again.

Not running SMP. runing 2.2.16-22 RH7.0

I haven't seen this occur again since I rm'ed the .ev-summary

Ok, so hopefully its just a corrupt summary not being repaired, i'll
investigate based on that.

I have another report with data that has the first 1K of the mbox
replaced with the first 1K of an ibex file (!).

So ... perhaps ... one or the other is using the wrong fd.

I just got bit by this, so we know the bug hasn't been fixed yet.
"Summary and folder mismatch, even after a sync".  I'll try the
workaround. (Wish I could append the folder, but it has work-related
stuff.)

I rm'd mbox.ev-summary and got the same error when trying the
expunge.  I think I'm willing to send mbox.ev-summary, but not the
mail contents. Would that help?

BTW, I'm running Evo 1.0 on RH7.1.

GNU gdb Red Hat Linux (5.1-0.71)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/evolution-mail 
[New Thread 1024 (LWP 23151)]
[New Thread 2049 (LWP 23239)]
[New Thread 1026 (LWP 23240)]
[New Thread 2051 (LWP 23241)]
[New Thread 3076 (LWP 23242)]
[New Thread 4101 (LWP 23245)]

Gdk-WARNING **: Missing charsets in FontSet creation


Gdk-WARNING **:     ISO8859-1

[snip! many such varnings...]


Program received signal SIGINT, Interrupt.
[Switching to Thread 4101 (LWP 23245)]
0x40aec966 in __sigsuspend (set=0xbf1ff94c)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
45	../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
	in ../sysdeps/unix/sysv/linux/sigsuspend.c
(gdb) thread apply all bt

+ Trace 16040

*** bug 219699 has been marked as a duplicate of this bug. ***

*** bug 215151 has been marked as a duplicate of this bug. ***

backtrace isn't much use in this case.

is your mailbox getting corrupted at all?

did you run out of disk or anything like that?

The summary file itself probably isn't much use either.

are you using smp machine?  any 'experiental' filesystems?

I have users who get this message too.  Here is some information:

- they are on an SMP machine running Debian Woody, kernel
  2.4.17-686-smp, Gnome Evolution 1.0.2 [] straight from the
  evolution_1.0.2-1.deb

- they are running directly from their mail spool, i.e.,
   /var/mail/USER (so I do not really know where evolution
   creates the .ev-summary and .ibex files for this)

- the mail spool directory is nfs mounted

- the mail gets delivered on a Sun machine running Solaris 2.6
  and sendmail (which also has the mail spool nfs mounted)

- they seem to have problems after new mail has been delivered
  to the spool; evolution does not detect this for some reason,
  but xbiff does; so when xbiff tells them they have new mail,
  they switch to another folder, then switch back to their spool,
  and then they get the message about "Summary and folder mismatch,
  even after a sync"

- given what I've read on this and other lists, it appears that it
  may be due to sendmail not respecting the locking method
  evolution uses; so evolution has the file locked because it
  is doing something, sendmail delivers the mail anyway, and
  evolution gets confused

- after the error message pops up, the user is unable to open
  any messages and so has to exit

- when they restart, their mbox has been corrupted and the first
  new mail message has been merged with the last old message

I hope this helps to get a resolution.  I am getting tired of
hand-editing their spool files.

dd

I've seen some reports of NFS locking on mailboxes not working
properly:  see bug 205095. 

Well, Solaris uses a different mailbox format, so you cannot really
use a direct spool to read your mail.  You have to set it up to copy
the mail from the spool to their local folders (i.e. choose the 'local
delivery' option, NOT the 'standard unix mbox spools' option).  If you
try using 'standard unix mbox spools', you will possibly get
corruption because 'standard' unix mbox spools dont use
content-length, but solaris sendmail does ... (although evolution
shouldn't change the content-length, perhaps sometimes it will because
of some other architectural issues).

This should at least, probably, stop the spool getting 'corrupted',
however some messages will still come through "chopped up", there is a
compile time option "--with-broken-spool=yes" that will make "local
delivery" work better with solaris's spool format, there is an open
bug on making this a run-time option at least, and also having it work
for the direct-spool-inbox case.

And yeah, it doesn't seem like the locking is working.  I used to have
similar problems on solaris systems with qpopper and other mail
clients, and got sick of the manual repair too.  Is there any specific
Solaris sendmail info on this?  I think we're relying on the '.lock'
mechanism mainly for this case.

Is the mail spool directory being mounted with 'actimeo=0' everywhere
it is being used (i think that is the option, on solaris anyway, not
sure with linux nfs)?  You normally have to do that with mail spools,
so that things like new mail are detected properly and more
importantly, checks for the spool being changed (based on
size/modification time) are accurate (which could also lead to mbox
corruption).

Evolution only checks for new mail if you ask it to (manually or
automatically), and i'm not sure if it was implemented for spool
folders anyway - but clicking on any message should detect new
messages too.

And finally, the 'resync' code is busted in some weird way.  Its
supposed to throw stuff away and re-try from scratch, but obviously isn't.

e.g. that error is only supposed to happen if it: tries to load a
message, but it isn't where it thought it was, re-scans the mailbox
and fixes up its offsets, and THEN tries to open the message and it
STILL isn't in the (new) right spot.  So it should be quite rare,
indicate something else is messing with the mbox when its supposed to
be locked, *and* it should auto-repair itself next time a message is
requested.  But obviously it isn't, and a lot of debugging hasn't
helped so far.

So:
 - verify actimeo=0 is set on the sendmail machine and all clients for
/var(/spool)/mail
 - use 'local delivery', not 'standard mbox spools', at least, till
its fixed.
 - optionally use --with-broken-spool=yes for solaris sendmail, or
expect the odd weirdly broken message.

I've been looking through the code, and the summary checking code was
a bit bunk in certain cases (e.g. if the mailbox had grown a little
bit, but it wasn't an appended message, it would wrongly assume the
file hadn't changed), and even worse in some (e.g. if the mailbox has
shrunk, it loses any unsaved changes rather than merging them).

I've started working on fixing these problems but its turning out
bigger than i'd hoped.  I also need to merge the spool/mbox code, so
this is easier to maintain.

Most of this has been fixed in head, but the changes are too big to
backport.

1.0.x is at end of life, so this can be closed since its fixed in 1.1.x

This bug is still present in 2.0.3, it just got reported to Debian's BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295270

Would it be that hard to:
1) Make a more verbose message, that says something like "this might
be because there's not enough space on the device"
2) Delete the corrupt summary (it's corrupt and useless, after all)
and try to rebuild it before showing the message?  This way, if the
user leaves evolution, makes some more free space and then starts
evolution again, he'll have everything fixed without having to delete
any of evolution's files.

I'm getting this with Evolution 2.2.2.

I ran out of disk space while emptying my trash folder. Now I can't expunge any
messages or empty my trash folder.

I ran into this bug too, with evo 2.2.2 + gnome 2.8 on debian unstable.

Deleted ~/.evolution/mail/local/Inbox.ev-summary and evo seems to have recovered.

*** Bug 315531 has been marked as a duplicate of this bug. ***

Deleting ~/.evolution/mail/local/Inbox.ev-summary don't recover anything for me
using 3.4.0 The bug shows up over and over again with different alternative
mboxes. It solves it temporarely for that evolution session maybe but it appears
again but then I have set automatic expunge. This bugs is basicly new to me and
occoured a couple of days before 3.4.0 final came out. I also get double entries
of mails in the list.

so retargetting that stuff (whou, 1.0.x target milestone - pretty cool)

Yeah, thanks for retarget'ing this one. That error is seriously deadly annoying.
Often run into lockups, double entry of the mails etc. I am quite curious that
this exists since 2001 since I first got aware of it around 1 month ago or so.
How comes this one got triggered 4 years later on me ? I did a new setup,
imported all my mails cleanly again and still hit the same issues.

*** Bug 319992 has been marked as a duplicate of this bug. ***

reassigning stuff that has been assigned to notzed. goodbye, dude. :-/

still in 2.5.2

*** Bug 327982 has been marked as a duplicate of this bug. ***

This is a highly annoying bug. Far too many users are affected and need to work around this, according to the duplicates. This bug comes up frequently on the mailing list as well.

Upping Priority.

*** Bug 332587 has been marked as a duplicate of this bug. ***

New comment from https://launchpad.net/distros/ubuntu/+source/evolution/+bug/27014

"Maybe i'm barking up the wrong tree, but maybe this info will help:

When I installed de Beagle-Evolution connector, Evo gave the problems. Uninstallation of the software restored the normal way of working.

I have not further tested it, but I thout it may be something to look at."

*** Bug 333202 has been marked as a duplicate of this bug. ***

Still a problem on 2.4.1.

Details that might help diagnose the problem:
* uname -a
Linux inferno 2.6.12-10-386 #1 Mon Jan 16 17:18:08 UTC 2006 i686 GNU/Linux
* P3, hyperthreading enabled, but non-smp kernel running.
* Ubuntu breezy
* No procmail, beagle, pop-watcher, or any other application running that should access .evolution/* in read or write mode.
* POP3 source.
* Exclusively occurs on Inbox, usually once or twice a week on evolution startup. Once evolution is up and running, the error doesn't seeem to occur.
* Quitting, removing .ev-summary, restarting, always fixes the problem.
* Problem occurred frequently on a .evolution directory that contained many, large, folders (100+ mb of total data - usually only a few mb in the Inbox though).
* A complete reinstall (archiving all old folders to CD, deleting .evolution, and .gconf/apps/evolution, but restoring the contacts DB) resulted in a week or so of no problems, but the bug surfaced again.

* $ df -H    (no disk space problems)
Filesystem             Size   Used  Avail Use% Mounted on
/dev/sda1              116G    30G    80G  27% /
...
* No NFS. Primary FS is ext3.

* du -sH .evolution/
7.6M    .evolution/

* ls -ald .evolution/ .evolution/mail .evolution/mail/local
drwxr-xr-x  8 myuser myuser 4096 2006-03-14 08:30 .evolution/
drwxr-xr-x  6 myuser myuser 4096 2006-03-14 08:30 .evolution/mail
drwxr-xr-x  7 myuser myuser 4096 2006-03-14 10:21 .evolution/mail/local

*  ps -ef | grep evol
myuser       8432     1  0 08:29 ?        00:00:00 /usr/lib/evolution/evolution-data-server-1.4 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_BookFactory:1.4 --oaf-ior-fd=45
myuser       8611     1  0 08:30 ?        00:00:00 /usr/lib/evolution/2.4/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.4 --oaf-ior-fd=57
myuser       8724     1  0 08:31 ?        00:00:18 evolution --component=mail
myuser       8727     1  0 08:31 ?        00:00:00 /usr/lib/evolution/2.4/evolution-exchange-storage --oaf-activate-iid=OAFIID:GNOME_Evolution_Exchange_Component_Factory:2.4 --oaf-ior-fd=55

Comment from Ubuntu bug: "After about a week the same error was back, even when the Evolution-Beagle connector wasn't installed"

very annoying, retargetting to 2.7

other Ubuntu comment: 

"

This bug is unfortunately still in Evolution 2.6.0, and it has plagued me at least two times this day again. Last time I said it was sporadic, but since I'm using Evo 2.6.0 on Dapper it happens nearly every day.

In the upstream bug report I read that this bug is retargeted to Evolution 2.7.0. That would mean waiting another half year and coping with this evil bug before 2.7.0 is released. This is such a severe bug, would it be possible for the Ubuntu dev's to backport a fix for this bug once this bug has been fixed in Evolution's CVS? Or if the Evolution team will do a bug fix release, 2.6.1 or something, will that new version be available for Dapper?"

I'm getting this bug as well with Ubuntu Dapper. I started using Evolution from scratch 2 weeks ago, this means that my folders are still relatively empty (I've got the error spunging Inbox, which has only 22 emails now). I'm happy to provide whatever file to a private email address.

From a UI perspective it would be good to give a hint to the user about this problem. Currently the error message tells you there is a problem, but doesn't give any solution, which is a really uncomfortable feeling for the users, that might very well think if their email messages are in danger.

If not a solution to the bug, a more explanatory error message (i.e. recommending an action and saying that this bug is known and Evo team is working on it) would smoother the problem.

BTW, this is totally subjective but I think a factor relating to this problem is to close the GNOME session (i.e. hitting the Log Out Button panel applet) with Evolution open. It looks like Evolution is not prepared to be closed when the shutdown process starts. Maybe if you close the session while Evolution is doing the regular 10' mailbox check... No idea, it's just a feeling.

** NICE **

I think I have a possible solution, for the few people who can't get rid of the "Summary and folder mismatch" condition, even after clearing metadata ! Please read on...

Today, I just had these error messages with Evolution 2.4.2.1. A few weeks before, my /home filesystem did run full while Evolution was "storing folders" on exit. This might be a possible cause (as some people mentioned on the web).

So, I tried to clear my metadata by stopping all evolution processes, wiping /tmp, and doing:

find ~/.evolution/mail/local -name '*.ev-summary' -exec rm '{}' ';'
find ~/.evolution/mail/local -name '*.ibex.index*' -exec rm '{}' ';'
find ~/.evolution/mail/local -name '*.cmeta' -exec rm '{}' ';'

Then, I restarted Evolution. It started reindexing everything, then seemed to fetch mail (which appeared in duplicates in the Inbox folder) -- and immediately, the error messages came up again !

So, clearing the metadata is not enough !  Before doing that, I *had* to go into Edit/Preferences/Mail accounts and uncheck the "Enabled" checkboxes on all accounts that can receive mail. *THEN* it worked, and no trouble anymore !

In short, while rebuilding indexes, it seems Evolution may run again into error condition if it's allowed to fetch mail at the same time !

Thoughts ?

Went into the same problem today (Ubuntu Dapper, evo 2.6.1). I have over 5000+ emails. I closed the gnome-session while evolution was running, perhaps storing something on disk. In order to get rid of the problem, I had to remove *.ev-summary while accounts were disabled. Removing *.ev-summary while accounts are enabled does not allow for the problem to be solved.
Hope it helps.

someone needs to make a tarball of the folder(s) that exhibit this behaviour when it does or it'll never get fixed because I can't reproduce it on my own.

Hi Jeff,

I'll gladly provide a tarball (I'd rather forward it directly, rather than as an attachment).  I'll also provide stack traces or whatever is required - just tell me what/how.

My situation is close to that described already in in Bug 315531; i.e. it is not related to expunging, but appears approximately every 3rd time I start evolution.  I have a clean installation of Fedora core 5, very few emails, a spool account, and a few message filters that move mailing list mail to dedicated folders.

I used yum to upgrade evolution* from the default fc5 distribution in the hope that it would help, but alas - same result.

When I delete the summary files, it fixes the fault for the next startup or so, but after another restart or two, I get the same error again.  Recently, I removed the entire ~/.evolution directory, and reinstalled evolution from the fc5 yum repos, but I get the same error, even with few new (i.e. previously unseen) mails in my spool.

I don't actually lose any mail, since when I delete the summary files, evo recovers OK, but I'm finding that I need to clean out the summaries around every 3rd restart.

This is driving me nuts.  Hope it can be fixed soon, since I'm a fan of evo, but this sort of cryptic error on startup makes it look lame.

Sidenote: can I suggest that reference to "expunging" in the summary of this bug be removed, since many bugs that aren't related to expunging have been tagged as duplicates.

Jason, if you could email me the tarball of the mbox, mbox.ev-summary, mbox.cmeta, and mbox.ibex* files to fejj@novell.com, that would be REALLY helpful.

(local mbox folders are located in ~/.evolution/mail/local/)

Thanks in advance.

*** Bug 341289 has been marked as a duplicate of this bug. ***

Ran evo under gdb, setting breakpoints at 

(gdb) break camel_mbox_summary_sync_mbox
(gdb) break mbox_summary_sync_quick

then stepped through function to try and determine where the error happens.  The gdb session is shown below.  I'm only a beginner with gdb, so let me know if I need to drill deeper for you.

I'm running evo 2.6.1.

Jason.

Breakpoint 3 at 0x6b852a7: file camel-mbox-summary.c, line 885.
Pending breakpoint "camel_mbox_summary_sync_mbox" resolved
Breakpoint 4 at 0x6b85ef4: file camel-mbox-summary.c, line 683.
Pending breakpoint "mbox_summary_sync_quick" resolved
[New Thread -1239438432 (LWP 7386)]
[New Thread -1249928288 (LWP 7387)]
[Thread -1249928288 (LWP 7387) exited]
[New Thread -1249928288 (LWP 7388)]
[New Thread -1291613280 (LWP 7389)]

+ Trace 68186

902             fd = dup(fd);
(gdb) next
903             if (fd == -1) {
(gdb) next
902             fd = dup(fd);
(gdb) next
903             if (fd == -1) {
(gdb) next
910             mp = camel_mime_parser_new();
(gdb) next
911             camel_mime_parser_scan_from(mp, TRUE);
(gdb) next
910             mp = camel_mime_parser_new();
(gdb) next
911             camel_mime_parser_scan_from(mp, TRUE);
(gdb) next
912             camel_mime_parser_scan_pre_from(mp, TRUE);
(gdb) next
Detaching after fork from child process 7456.

(evolution-2.6:7351): camel-local-provider-WARNING **: Didn't get the next message where I expected (3337006) got 236581 instead
[Switching to Thread -1249928288 (LWP 7388)]

Breakpoint 3, camel_mbox_summary_sync_mbox (cls=0x94d8450, flags=0, changeinfo=0x94d5c48, fd=41, fdout=43,
    ex=0x9274fc8) at camel-mbox-summary.c:885
885     {

thank you Jason, this narrows it down much more.

It seems that somehow the parser is finding a MIME message From-line sooner than it expected to find (the next) one in the mbox file (found one at byte offset 236581 when it didn't expect to find it until byte offset 3337006).

*** Bug 341711 has been marked as a duplicate of this bug. ***

Well that helps.  I guess I got to go find when 2.7 release is planned.  

I opened the Debian bug mentioned in Comment #27.
Good info there: http://bugs.debian.org/295270

Anyway...

Has anybody tried valgrind yet? There seem to be
a number of bug reporters who are easily able to
reproduce this bug. If any of them have a fast PC,
they ought to do this:

valgrind --tool=memcheck evolution

Testing all evolution features in valgrind would
be a great idea. You can also use --tool=cachegrind
to find performance problems.

(sorry I can't do this: using PowerPC, plus I had to
give up because the bugs were overwhelming)

Happy to valgrind evolution next time the bug appears..

Additional comments though:
* I haven't seen the problem since updating to ubuntu dapper beta a few weeks back, (evolution 2.6.1-0ubuntu7).
* The last few times I saw the problem on breezy, a quit/restart of evolution was enough to fix the issue for that session.
* In the last 6 months, the problem only seemed to crop up on evolution startup. Normal send/receive activity didn't provoke the bug.

*** Bug 343461 has been marked as a duplicate of this bug. ***

OK, I am happy to do it.
this is exactly the same code and it rolled right along..
This is the last entry before I ^c the process.

(evolution-2.6:9633): evolution-mail-WARNING **: ignored this junk plugin: not enabled or we have already loaded one

(evolution-2.6:9633): e-utils-WARNING **: Plugin 'Spamassassin junk plugin' failed to load hook 'org.gnome.evolution.mail.junk:1.0'
Setting up initial mail tree
addressbook_migrate (0.0.0)
==9633==
==9633== ERROR SUMMARY: 212 errors from 22 contexts (suppressed: 217 from 2)
==9633== malloc/free: in use at exit: 1,156,330 bytes in 21,628 blocks.
==9633== malloc/free: 69,451 allocs, 47,823 frees, 5,353,682 bytes allocated.
==9633== For counts of detected errors, rerun with: -v
==9633== searching for pointers to 21,628 not-freed blocks.
==9633== checked 3,015,316 bytes.
==9633==
==9633== LEAK SUMMARY:
==9633==    definitely lost: 4,571 bytes in 76 blocks.
==9633==      possibly lost: 59,784 bytes in 319 blocks.
==9633==    still reachable: 1,091,975 bytes in 21,233 blocks.
==9633==         suppressed: 0 bytes in 0 blocks.
==9633== Use --leak-check=full to see details of leaked memory.

you need to paste the entire log or it's useless

still can't find this bug :\

Jeff,

Some more data points for you.

As this fault manifests with me, it seems to come in bursts.  i.e. I've had a couple of weeks without many "mismatch" errors, then over the last couple of days it occurs just about every second time I start evo (because every time I get the error, I do the rm *ev-summary thing, and that allows it to restart cleanly).

By just being witness to the crash patterns over some months, my gut feel about the cause of this bug (as it occurs on my system, anyway) is that it is related to moving mail out of my inbox (which is a unix spool), and into local evo folders.

I have about 5 or so filters that place new mailing-list emails into separate evo folders, and I often move emails from the inbox to other evo folders manually too.  I reckon that even though the mail has been moved from the spool and placed into the local folders (as evidenced by the unix filesystem), the evo indexing system still thinks that the mail resides in the spool file.  

Today, I tried manually doing an expunge (using ctrl-e) in every local evo folder, and I have not had a "mismatch" error after around 10 restarts of evo, which is significant given that it has been crashing so frequently of late.  So I'm thinking that I manually forced evo to reconcile the email "movements", even though it should be doing this behind the scenes.

Just a hunch...

I don't follow... what kind of account setup do you have?

I can paste the entire log, however it may be a huge file.
This is not the right syntax to get it all on a file. (I know because it failed)
wolf@l8:~$ sudo valgrind -v --tool=memcheck evolution | less > /home/wolf/Desktop/evo.leak
The run of this log will be from before Evolution opens, through a test email send and another send and receive, a delete and an expunge of the inbox and the local folder the messages are being filtered into.  I am trying to get the error while the test is running.  Is there a better way to set up this test?

use: valgrind --tool=memcheck --alignment=8 --error-limit=no --num-callers=16 --log-file=evo.log evolution

attach evo.log.<pid>

the log file keeps coming up empty, but at least it isn't running a display on the terminal

(In reply to comment #63)
> By just being witness to the crash patterns over some months, my gut feel about
> the cause of this bug (as it occurs on my system, anyway) is that it is related
> to moving mail out of my inbox (which is a unix spool), and into local evo
> folders.
> ..
> I have about 5 or so filters that place new mailing-list emails into separate
> ..

Just to flesh out the potential area-of-investigation a little, my inbox is local (pulled in from POP3), but I also have filters in place that move emails automatically to target folders.

(In reply to comment #64)

My "receiving mail" configuration is "standard unix mbox spool or directory".  I'm running under fedora core 5.  It's a personal account with low email throughput, and I've been seeing this issue since installation of fedora core 5, which was done on a freshly formatted disk (i.e. clean installation, not upgrade).  I had no such issues under fedora core 4.

*** Bug 343578 has been marked as a duplicate of this bug. ***

Jason, I'd suggest using "Local Delivery" instead of "Unix mbox spool or directory", it wasn't really meant for pointing at /var/spool/mail and is probably why you are having these problems.

This bug has plagued me on and off for years, but it does seem to have gotten worse recently.  Possibly because of this PREEMPT kernel (Ubuntu Dapper).

If you delete the .ev_summay file and go into offline mode, it settles down.  I am guessing that it's longstanding a race somewhere between adding in new mail, and manipulations on existing mail.

Once it fails to sync, it doesn't seem to clear its internal cache of new mail, and so it gets added again, and again, and again...

Hope this offers a clue,
Rusty.

Well, I had removed all of the .ev_summary files before I submitted the bug.  The only thing I had not done was to take evolution offline.  I once again removed the files and then took it offline but I get the same frustrating error.  For me, it is urgent as I have over 2000 files I must remove as they are just wasting disk space.
I can most probably fix it by renaming the .evolution folder and restarting the program which naturally, will rebuild the base folders etc.  I could then reimport all of my mail but I lose my address book and I am unsure how to retain that.
Thanks,
Rick

Rick,

To resolve the problem, please try doing as indicated in comment #48:
1 - !! temporarily disable incoming mail accounts !!
2 - close evolution and evolution-data-server
3 - delete the .ev-summary files

Joël,
I have carried out all of the steps in comment #48 = now for the 4th time - and have even removed the contents of my tmp file.  This all succeeded in trashing my install.  I have now re-installed the same version (2.4.1) and after watching all of my folders rebuild beautifully, I have to report that nothing has changed.  I get the identical error and nothing is deleted.

I have used Evolution since version 1.1 and have never experienced problems like I am right now.  Think it's time I revisited kmail or Thundebird.  I have had enough of this.

Thanks for your help anyway.

Rick

going offline doesn't affect local folders

*** Bug 344878 has been marked as a duplicate of this bug. ***

Thanks Jeff,

Two weeks after changing my mailbox type to "local mailbox" as suggested in comment #71, I have not had a crash.  This issue now appears to be resolved from my perspective.

Just a thought: I was fooled by the wording in the UI - I chose "unix spool" because that's where I was pulling my mail from.  Even reading the description again now, the use of this option is not clear.  Also, I don't think it's mentioned in evo help.

Jason: I expect that several people here have been using "Local delivery" (with /var/spool/mail/myuser) from the beginning (at least I have), and yet, the problem happens.

And even more people are using POP3/IMAP, yet hitting the problem.

*** Bug 345112 has been marked as a duplicate of this bug. ***

I agree with everyone above who has commented that this bug has significant data loss potential (see rant, below).  I hit this error about once every two weeks.  

I'm using:

Evolution 2.6.2 in POP3 mode (RPM: evolution-2.6.2-1.fc5.5)
Fedora Core 5 with daily yum updates of all components, including kernel
71GB free on an ext3 local filesystem (disk has never been full or experienced problems)
2.6.16-1.2133_FC5smp (and I've hit this on all previous FC5 SMP kernels)
du -sh .evolution--> 393M    .evolution/

I see the following messages at the same time as the evolution error in /var/log/messages, although I do not know if these messages are relevant:

Jul  6 10:00:37 hostname gconfd (username-1576): starting (version 2.14.0), pid 1576 user 'username'
Jul  6 10:00:37 hostname gconfd (username-1576): Resolved address "xml:readonly:/etc/gconf/gconf.xml\
.mandatory" to a read-only configuration source at position 0
Jul  6 10:00:37 hostname gconfd (username-1576): Resolved address "xml:readwrite:/home/username/.gco\
nf" to a writable configuration source at position 1
Jul  6 10:00:37 hostname gconfd (username-1576): Resolved address "xml:readonly:/etc/gconf/gconf.xml\
.defaults" to a read-only configuration source at position 2
Jul  6 10:00:42 hostname gconfd (username-1576): Resolved address "xml:readwrite:/home/username/.gco\
nf" to a writable configuration source at position 0

begin rant
I just lost all my new mail from overnight because I made the mistake of closing Evolution after retrieving my messages from the POP server and getting this error, although based on everyone's comments, I doubt that there was anything I could to save my data do once evolution got into this state.  I'm going to try to switch to IMAP as a method of protecting myself if I can get our IT group to do it, but as a software developer, I'm horrified by this behavior, and by the fact that this bug has been for *FIVE YEARS*.  I didn't notice that this bug had been open for so long when I started writing this comment.  I've used Evolution since 2001/0.9-era, but I'm investigating switching to Thunderbird based on that datapoint.  
end rant

Ok, I feel better now.  I'm a C developer, although I mostly write Linux device drivers, so Gnome apps aren't exactly my specialty, but I'll try to do anything I can to help.  Is there anything in particular that would be helpful?  I've put myself on the cc: list for this bug.

fejj, any news?

Ubuntu 6.06 LTS, Evolution 2.6.1 with newest stable upgrades

Now this bug appears in different situation. I launch evolution, it starts up
very slowly, first of all in INBOX there is no emails, then after 5 secs all
already read messages appear, and then after long time - unread messages. And
then it crashes - and sometimes not.

After little investigation I get that it was that Inbox.ev-summary file in
.evolution/mail/local wasn't created after deletion (see workaround at comment
#3). I just got popup menu for Inbox folder, choosed Properties, and then
clicked simply OK. Evo got that is has to create summary file, seems to me, and
so, now it again works like charm.

I hit this bug again this morning.  Removing ~/.evolution/mail/local/Inbox.ev-summary does not cure the problem.  I have not restarted evolution, which I know will cure it.  I've got gdb attached to the process, but I am unsure what I'm looking for.  If anybody has any suggestions, they would be greatly appreciated.  

Dave: if it doesn't work even after deleting the summary file, then odds are the mbox file really is corrupted.

if it's not a personal mbox, could you bzip2 it and send it to fejj@novell.com?

Dave, I suggest to try my method with getting Properties dialog for INBOX folder in Evolution and press OK, while ensure that indexing option is checked. It solved problem for me.

Jeffrey, unfortunately, it's a personal and corporate inbox, so I can't send it to you.  I can try to grab any info you need though.  I'm virtually certain the mbox isn't corrupt, though, as restarting evolution has always cured the problem when I've hit this in the past.  

Peteris, I tried getting properties and clicking ok, but no joy.  I still get the mismatch messages.  

BTW, to get the mismatch messages, I'm clicking on my Inbox folder, and then on my Trash folder.  Each time I get a message, although slightly different.  Just so we're all on the same page, I'm attaching a screengrab of the dialogs.  

I've still got evolution in this state, btw.

Created attachment 69176 [details]
screengrab of error message box

Created attachment 69177 [details]
screengrab of error message box

does the Inbox folder mbox start with "From " ?

I've only seen 2 mboxes where this wasn't fixed by deleting the summary files, and neither of them started with "From "

one was perfectly fine other than not having the "From " line, the other had about 1k of the contents of another file written to the head of the mbox (overwriting part of the first message).

Inbox does start with From

Is there a definitive test I could run against the Inbox that would tell us if it is corrupt?  I really don't want to restart evolution when there's a possibility I could get more info from the process.

I had to restart evolution, which cured the problem.  Sorry I couldn't get you any more info.  

I'm worried, that this bug will not be fixed in Evolution 2.8. GNOME 2.16 will be released on September 6th, leaving little more than one month for a fix to arrive :(

Even though the priority is marked urgent, and the severity is marked as major, and the target is 2.7, this bug was first reported in 2001 and there still doesn't seem to be a fix in the works if I read the comments here.

Can anyone please explain how the progress on fixing this bug is going? Is this bug very difficult to fix?

When we will be using Evolution 2.8 in a few months, we will see some great new features - http://blogs.gnome.org/view/sragavan/2006/07/19/0 - but we we'll likely still have to cope with this bug, unfortunately. IMO fixing bugs is more important than new features, software can have great features but if it's full of bugs it isn't of much use. I'm seriously considering switching to Kontact or Thunderbird just because of this bug.

And if you take a look at Bugzilla's reports - http://bugzilla.gnome.org/reports/weekly-bug-summary.html - Evolution takes the lead with 1477 (!) bugs. Maybe it would be a good idea for the 2.10 release to forget about new features, and concentrate on bug fixing and polish only?

 

Even I would like to see this problem to be fixed. It's now permanently shifted from one version of Evolution to another and no one seems to know what the cause is. Good to know that this has been reported by several individuals. I think it should be Novell's interest to have their highly praised PIM suite work for everyone.

I think I stumbled on a new datapoint this morning.  I hit the bug again and realized I often hit it on Monday mornings.  What's different about Mondays is that over the weekend, I often ssh into my box & start Evolution over the forwarded X session.  When I log out, I always have to kill some process that's hanging around after Evolution exits--note: this is only true if I start Evolution, normally I can log out just fine.  I believe that there is a relationship between the ssh sessions and this bug.  I am swamped this morning, so that's all I have right now, but I will try to set up a test account and get a reproducible test case shortly.  

ali: if you've got a support contract with novell, feel free to post bug reports to https://bugzilla.novell.com. if not, feel free to fix this issue - this is open source and evolution is part of gnome, not of a company. ;-)
(my personal opinion; no offense intended)

The following ps snippet is the process that was preventing me from logging out, although I also killed evolution-data-server-1.6, so that may also have been preventing the logout.  I logged in as root from another shell & killed both processes (alarm-notify & data-server) and my SSH session for my test user immediately completed (I had previously ctrl-D'd it).  

501      15072  0.0  0.8  60188  8328 ?        Sl   21:48   0:00 /usr/libexec/evolution/2.6/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.6 --oaf-ior-fd=25

I'll try starting evolution from the local machine tomorrow morning when I get in and see if I reproduce it.  

I didn't hit it this morning with my test user, but that's not at all surprising as the test mailbox is empty and I didn't create any new mail...I don't really have enough time to do this investigation right, but I'll keep trying as I can.

Thanks Dave, your digging is much appreciated.

I still can't figure out what is causing this, but it seems to be related to evolution-data-server or evolution-alarm-notify not shutting down cleanly. And it only seems to happen when I have received new mail since I last opened evolution. As a work around, I created a script that runs:

evolution --force-shutdown
evolution &

And I haven't seen the problem since.

I got this today again, and right before it happened, I clearly noticed that it was fetching mail (new mail) *and* storing folder (emptying trash?) at the same time.

I want to second last comment too. It is definetly something out of order while fetching mail and building index of inbox file. If it is so, should be definetly easy to look up it.

Hmm. Evolution goes from showing a dialog about how it's checking mail on startup (after a small delay)... to quickly and silently checking mail much sooner after startup.

At the same time, people start experiencing these "sync" problems in their inbox. 

Coincidence? Come on guys, this looks like a race. You need to fix the race between send/receive and other mailbox activities that probably occur on startup (and god knows, at other times). 

Could we lose data from this? Who wants to bet?

With a bug this big and critical going basically undiagnosed and unfixed for this long, it makes you wonder if Evolution is a safe place to put your data.

Be advised all: back up often...

I agree with last post - it definetly looks like send/recieve problems while starting up/shuting down Evolution. Something gets out of hand and out-of-sync accours. 

Another possibility is that is connected with leaving messages on server in POP3 usage. So anyone else using this option checked while expierencing this bug?

Re: leaving msg on server, I am experiencing the problem when NOT leaving messages on the server.  

I think the possible connection between this bug and SSH usage that I mentioned earlier is not at fault.  I've seen the problem when I know I haven't SSH'd in and I've SSH'd in and not seen the problem.  Obviously there still could be a connection, but it's definitely not 100% reproducible, and I'd guess probably just coincidence.  

*** Bug 354800 has been marked as a duplicate of this bug. ***

Any progress on this?  It's only been known for 5 YEARS...

I have not seen the error for a couple of weeks.  Now the only thing that happens is an occasional crash during shutdown - after I have hit the (X) to shut down Evo, an error comes up saying that evo shutdown unexpectedly.  This is odd, since I Did expect evo to shut down.

hehe, that error dialog means it crashed, Wolf ;)

lol! Crash on close is like your car coming to a halt and alerting you that the brakes were on when you were pressing the brake pedal, methinks.  
a) Is this just some other bug, or 
b) did what fixed (or appeared to fix) this bug break something else?  

I didn't experience this crashing before, so I am leaning toward interpretation (b)

per comment 105  Peteris --  I don't leave messages on the server..

Crash on close is as serious as any other crash, because it often leads to corrupt data if the application is not careful, as seems to be the case with Evo.

I think this bug may be associated with crashes on close - it seems that if Evo crashes or (especially) hangs for a long time on shutdown, it's more likely that "Summary and Folder mismatch" will appear on the next startup.

One could probably reproduce this bug by repeatedly kill -9'ing Evo and starting it again.

I think Lee's probably right on this one, as disorderly Evo shutdown is what's happening when I have to kill processes after exiting Evolution started in an SSH session.  I have no reproduction case using SSH, but my gut feeling is that I see this bug more often after using SSH (and killing processes on exit).  It might not be Evo that has to be kill -9'd; it might also be evolution-data-server or evolution-alarm-notify, I'll take a wild guess and say it's data-server, not alarm-notify, but who knows.  I'm trying it as a reproduction case now.

Well, I've got a test case running.  I haven't let it go much during the day today but I'm going to let it run over the weekend and review the logs on monday.  According to the code in evolution-data-server/camel/providers/local/camel-mbox-summary.c I should see either "Expected a From line here, didn't get it" or "Didn't get the next message where I expected (%d) got %d instead" (with %d replaced, obviously...) in my log if it repros.  If anybody thinks I should look for any other strings, please let me know.

I've let it run overnight a couple of times (~500 iterations) with no repro.  :(    The test account was subscribed to LKML, so its mailbox has a couple of thousand messages in it by now, so I don't think its a question of mailbox size.  

I'll attach the script I used so if anybody wants to make suggestions, I'll listen.  Otherwise, I'm done with this test.

Created attachment 73142 [details]
Attempt at repro case using kill -9

This script was not successful at reproducing the bug.

Please tell me *exactly* what information you need from me the next time I hit the bug.

You also might want to try it with a disk that sometimes fills up, I suspect Evo doesn't handle that well.

Lee, If your request for what information to report next time was directed to me, unfortunately I'm in the same boat you are.  I'm not an Evolution developer, I'm just an evo user who hits this bug regularly and who happens to be a sw developer.  I'm just doing what I can to troubleshoot it and keep it on the development team's radar.  I'm afraid that, other than a *very* brief examination of the code, I don't have any real understanding of what's going on under the hood.

Re: disk filling up, in my case I've got more than 70GB free (and have for the life of the machine), and I hit this bug fairly freqently, so for me at least I can rule that out as a cause.  

Sorry I can't provide an answer to your request; if anyone on the ticket can answer it, please do.  

Dave

*** Bug 357125 has been marked as a duplicate of this bug. ***

*** Bug 357906 has been marked as a duplicate of this bug. ***

I have been getting this problem quite often now since upgrading to either evo 2.2.x or 2.4.x. I also have mail initially delivered into a unix mail spool (/var/spool/mail/seb) and I point evolution at that as my inbox. I too have several filters which copy mails straight out of the spool into local folders in my .evolution directory.

I now have evolution 2.6.2 on Gentoo. I removed the Gentoo packages and compiled a debuggable version of 2.6.2 and I will try to figure out what is up. However, I agree with David Wood that this looks like a race and as I am not an evolution developer it may take some time before I understand the code. I'm pretty busy on other things, but this is impacting on my day to day work so I'd love to get a fix for it.

Now, I could change to "Local delivery" from "Standard Unix mailbox spool" and perhaps that would help, but I see no reason why evolution shouldn't use the spool as a folder and this really is a bug which requires a fix not a workaround.

I don't think this bug is specific to any mail storage method - I use POP3 and have been afflicted for years.

The other possibility is that there are multiple bugs with the same symptoms.

Ok, so not restricted to one mail storage method. Maybe this is due to the fundamentail design of the code and this problem shows up more often for some mail storage methods and less for others.

The trouble with this one is that it is quite hard to reproduce on a reliable basis - it seems for me to occur more in the mornings on busy mail days. In fact, I will subscribe to lkml and create a filter to copy those messages into a local folder from my unix mail spool inbox.

I just hit it for the first time on my test account which had started evolution from a shell.  The following appeared on the console:

(evolution-2.6:11374): camel-local-provider-WARNING **: Didn't get the next message where I expected (30101574) got 30111920 instead

(evolution-2.6:11374): camel-local-provider-WARNING **: Summary doesn't match the folder contents!  eek!
  expecting offset 22868444 got 22873178, state = 2

I have been really busy and had forgotten to check email on that account for a while, so it had 1600+ new messages and 4400+ in the trash, which seems to agree with Sebastian's comment that it happens more in the morning on busy mail days.  On my regular mail account, I have only seen it on first mail check in the morning.  

The evolution directory for that account is now pretty big, but it's got nothing confidential in it, so I can provide it if it would be helpful.  

I didn't take the time to read each post in depth so if this comment is old news please forgive me.  

I decided yesterday to give evolution a try instead of continuing with gmail's online interface.  So I setup the account and started the long process of downloading several hundred megabytes of messages.  Wanting to mirror the organization on gmail I had all messages downloaded into one folder (all mail) then set up search folders as a crude attempt at labels.  While messages were downloading I would change various filters/search folders and move a few messages around.  It seemed that anytime I did this I would run into this bug.  If I just left Evolution alone while mail was downloading I had no problem.

I hope this helps in debugging.  If there is anything I can provide you with, let me know.  I'd be happy to oblige.

I can confirm the behavior that David Berg is seeing.  With 6k+ mails in trash and 1800+ mails in my inbox and two search folders, and more mail downloading, I cannot switch folders without seeing the bug.  

It seems to be present only while new mail is downloading.  Now that all my new messages have come down I can switch folders without hitting it, although it looks like I have lost 1500 messages.  Perhaps that's a cosmetic thing, but a minute ago it said I had ~3100 messages in my inbox; now it says I have ~1500, and I didn't delete any.  I haven't counted them myself.  :)

*** Bug 363013 has been marked as a duplicate of this bug. ***

*** Bug 363877 has been marked as a duplicate of this bug. ***

I use Evolution 2.6.1 (ubuntu 6.06) and I have that problem every time i enter a sub directory in my inbox.

200610220400NZDT~

Tshiba Satellite 366MHz with 192MB running Ubuntu 6.06 fully up to date with distribution copy of evolution 2.6.1.

Linux t2550cdt 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux

I was scp-ing ~100MB of image files into a folder on the desktop from another machine on the lan..

When I found the machine it was frozen except for the bios keyboard funtions. The scp transfer was incomplete one of the files was incomplete/corrupt. There is ample free disk space.

On rebooting the only significant log messages were:
Oct 22 04:08:15 localhost kernel: [   29.226427] Attempting manual resume
Oct 22 04:08:15 localhost kernel: [   29.283123] EXT3-fs: INFO: recovery required on readonly filesystem.
Oct 22 04:08:15 localhost kernel: [   29.283145] EXT3-fs: write access will be enabled during recovery.
Oct 22 04:08:15 localhost kernel: [   35.477929] EXT3-fs: hda1: orphan cleanup on readonly fs
Oct 22 04:08:15 localhost kernel: [   35.478054] kjournald starting.  Commit interval 5 seconds
Oct 22 04:08:15 localhost kernel: [   35.720664] ext3_orphan_cleanup: deleting unreferenced inode 1687829
Oct 22 04:08:15 localhost kernel: [   35.721187] ext3_orphan_cleanup: deleting unreferenced inode 1687828
Oct 22 04:08:15 localhost kernel: [   35.721246] ext3_orphan_cleanup: deleting unreferenced inode 1687827
Oct 22 04:08:15 localhost kernel: [   35.721295] ext3_orphan_cleanup: deleting unreferenced inode 1687826
Oct 22 04:08:15 localhost kernel: [   35.721346] ext3_orphan_cleanup: deleting unreferenced inode 1687825
Oct 22 04:08:15 localhost kernel: [   35.721397] ext3_orphan_cleanup: deleting unreferenced inode 1687823
Oct 22 04:08:15 localhost kernel: [   35.721446] ext3_orphan_cleanup: deleting unreferenced inode 1687822
Oct 22 04:08:15 localhost kernel: [   35.721497] ext3_orphan_cleanup: deleting unreferenced inode 1687820
Oct 22 04:08:15 localhost kernel: [   35.721546] ext3_orphan_cleanup: deleting unreferenced inode 1687817
Oct 22 04:08:15 localhost kernel: [   35.721599] ext3_orphan_cleanup: deleting unreferenced inode 1687562
Oct 22 04:08:15 localhost kernel: [   35.721656] ext3_orphan_cleanup: deleting unreferenced inode 1687560
Oct 22 04:08:15 localhost kernel: [   35.721709] ext3_orphan_cleanup: deleting unreferenced inode 1687559
Oct 22 04:08:15 localhost kernel: [   35.738547] ext3_orphan_cleanup: deleting unreferenced inode 1687557
Oct 22 04:08:15 localhost kernel: [   35.748031] ext3_orphan_cleanup: deleting unreferenced inode 1672131
Oct 22 04:08:15 localhost kernel: [   35.759729] ext3_orphan_cleanup: deleting unreferenced inode 1673884
Oct 22 04:08:15 localhost kernel: [   35.783876] ext3_orphan_cleanup: deleting unreferenced inode 1688716
Oct 22 04:08:15 localhost kernel: [   35.783955] ext3_orphan_cleanup: deleting unreferenced inode 1688707
Oct 22 04:08:15 localhost kernel: [   35.784010] ext3_orphan_cleanup: deleting unreferenced inode 1688696
Oct 22 04:08:15 localhost kernel: [   35.784066] ext3_orphan_cleanup: deleting unreferenced inode 1688691
Oct 22 04:08:15 localhost kernel: [   35.784117] ext3_orphan_cleanup: deleting unreferenced inode 1688690
Oct 22 04:08:15 localhost kernel: [   35.822140] ext3_orphan_cleanup: deleting unreferenced inode 114696
Oct 22 04:08:15 localhost kernel: [   35.844715] ext3_orphan_cleanup: deleting unreferenced inode 114695
Oct 22 04:08:15 localhost kernel: [   35.882206] ext3_orphan_cleanup: deleting unreferenced inode 1677404
Oct 22 04:08:15 localhost kernel: [   35.915958] ext3_orphan_cleanup: deleting unreferenced inode 1706605
Oct 22 04:08:15 localhost kernel: [   35.927395] ext3_orphan_cleanup: deleting unreferenced inode 1706604
Oct 22 04:08:15 localhost kernel: [   35.942302] EXT3-fs: hda1: 25 orphan inodes deleted
Oct 22 04:08:15 localhost kernel: [   35.942317] EXT3-fs: recovery complete.
Oct 22 04:08:15 localhost kernel: [   35.989145] EXT3-fs: mounted filesystem with ordered data mode.

Thereafter evolution sporadically presented pairs of popup errors, from memory one saying it couldn't store the folder and the other that it couldn't fetch email, generally similar to the screenshots attached to the bug. ~"folder contents don't match index even after a sync" on folder Filtered/logs. These went away after a dozen or so times and things seemed ok again.

The account is configured to use pop3 and to leave copies of messages on server.

I checked that the mbox file started with "From:".

Over the day, while away from the machine, I rewired some of the network between the machine and the internet at large including it's pop3 server.

200610230415NZDT

On returning to the machine again:

"Error while Fetching Mail.
Cannot get message phoneybaloneygoofyuidl: Connection timed out."

Now have unread duplicates of all messages up to the time that I was messing with the network.

Note that these duplicates were not downloaded until after the macine had been running for some hours.

I have two questions:

Does the program disable mail send/receive operations while building indices/syncing ?

How does it deal with the filesystem going bad underneath it ?  

> I have two questions:
> 
> Does the program disable mail send/receive operations while building
> indices/syncing ?

no, it indexes as part of the send&receive operation

> How does it deal with the filesystem going bad underneath it ?  

if it notices that the indexes are borked, it rebuilds them when it opens a folder (best we can do).

(In reply to comment #132)
> > I have two questions:
> > 
> > Does the program disable mail send/receive operations while building
> > indices/syncing ?
> 
> no, it indexes as part of the send&receive operation

So what happens if a second Send/Receive occurs before an indexing operation is complete ?

I'm pleased to report that the program has been running well since my previous report.

Is there a fiendish plot to dispose of duplicate emails ?

a second send&receive can't start for that particular provider until it is finished

Please see:

https://launchpad.net/bugs/27014

I think this bug is actually multiple bugs.  I seem to be having the same issue as the Ubuntu bug reporter: this error is associated with transient disk-full conditions which Evo does not seem to handle correctly.

I do not believe that the failure which led to me experiencing this bug was a disk full error.

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1              18G  4.1G   13G  24% /
varrun                 94M   96K   94M   1% /var/run
varlock                94M  4.0K   94M   1% /var/lock
udev                   94M   84K   94M   1% /dev
devshm                 94M     0   94M   0% /dev/shm
lrm                    94M   19M   76M  20% /lib/modules/2.6.15-27-386/volatile

Mark: that's why I think it's more than one bug with the same symptons.

It should be trivial for someone familiar with the sources to verify by code inspection that Evo handles disk-full conditions properly.

Even on a fresh install with Ubuntu Dapper, the issue arises sometimes.  Not able to switch from folder to folder without seeing the errors and occasionally finding that the expunged emails are fed back to their folder of origin twice - giving me 2 copies of stuff I thought I had already dealt with.

I wish I could tell you that I was seeing anything different in the environment between successful sessions and unsuccessful sessions.

*** Bug 368103 has been marked as a duplicate of this bug. ***

A few different ideas:

Regarding valgrind, I hope it was clear that valgrind would need to be run on a known-good mailbox with expected FUTURE corruption. The idea is to catch the corruption when it is created; the after-effect is not so interesting I think.

There is a very logical argument that crash-on-close should be what happens every time! First of all, you have to plan for crashes. People lose power, kill processes, and get OS crashes. Thus your app must robustly handle death at any moment. (all operations must be atomic) Given that your app is able to robustly handle death at any moment, you can use raise(SIGKILL) to shut it down. This gives you two huge benefits: speed, and one less code path to maintain/debug.

For robust mailbox handling, a shared-nothing approach is wise. You create a socket, fork, close all file descriptors except the socket (see the dup2 function), exec something like /usr/lib/evolution/mbox-handler, call alarm(42) or similar, call prctl(PR_SET_PDEATHSIG,SIGKILL,0,0,0) if that function exists, read config data over the socket, open the required files, write a 1 to /proc/self/seccomp if that exists, process the data as requested, tell the GUI what happened, and then just die. (Note: no threads here!) Repeat as required. It is safest to have the child die after handling just one operation.

IMHO, it is not unreasonable to redesign if a horrible bug goes unsolved for over 5 years.

*** Bug 381390 has been marked as a duplicate of this bug. ***

One of our Debian users experienced the "transient disk full" version of this bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295270#114

He has a copy of the corrupted mailbox summary. If someone wants to look closer at the summaries, contact him directly, or go through me.

Ok, I'm making a bit of progress on this now. I'm looking at: evolution-data-server-1.6.2/camel/providers/local/camel-mbox-summary.c

I'm working on this version not the latest, simply because it was the one that matches my system.

There are several points in the functions camel_mbox_summary_sync_mbox() and mbox_summary_sync_quick() where this bug can manifest itself. For me, it is _always_ at one point - in camel_mbox_summary_sync_mbox() (which is called by mbox_summary_sync_full()) and it is always after this piece of code:

if (camel_mime_parser_tell_start_from(mp) != info->frompos) {
 /* Then you get the error */
}

That is, line 941 in the evolution-data-server-1.6.2 camel-mbox-summary.c.

For others a different part of the code may be triggering the bug, but this is the one for me (I am using a unix mail spool as my Inbox).

The problem is that the position of the message stored in info->frompos is different from the one measured by camel_mime_parser_tell_start_from(). 

This can occur if the mailbox has changed between the time of storing frompos in info, and the time at which line 941 is executed. If the mailbox is changing often, as it may be if emails are being received while the user is viewing the mailbox, then this appears to be quite likely. For me it happens several times a day.

The solution would seem to be to re-scan the mailbox if info->frompos doesn't seem to match the mailbox, rather than the goto error in the code as it stands.

I'm trying some different ways of doing that at the moment.

If anyone wants to try patching camel-mbox-summary.c then let me know. The changes I have made so far are: 

I added some extra debugging output, so that you can tell where in the code the error is occuring.

I've stuck in a goto rescan; hack, which sends program execution up to just before the line:

info = (CamelMboxMessageInfo *)camel_folder_summary_index(s, i);

And this appears to have removed the symptoms.

I'll post a patch if and when I get a real fix.

once again, for the records:

If you get an error popup like:
"Error while Expunging folder. Error storing `~/.evolution/mail/local/Inbox (mbox)': Summary and folder mismatch, even after a sync.", try removing the corresponding file with the file ending ".ev-summary", in this example you should remove the file "~/.evolution/mail/local/Inbox.ev-summary".

Workarounds are nice, but any idea when this will really be fixed?

My goto rescan hack mentioned in comment #143 doesn't work.

Ok, I'm a bit out of date as I'm using the latest stable on Gentoo-x86-64 which is 2.8.2.1 but I tried the rm Inbox.ev-summary trick and then restarted evolution and got the same error.  Worse after it finished indexing the mail I got two copies of everything in Inbox.  And it did not recreate the Inbox.ev-summary file.  I thought it might recreate it on exit so exited and checked and no Inbox.ev-summary but when I restarted it there was only one copy of each message (which was nice) and the error seemed to go away.  It also created the Inbox.ev-summary file.

For what it was worth the headache started when I tried to do something and ran out of disk space.  (I don't remember the exact operation as it was quite a while ago).  It seems to all be fixed now though.

This bug happens to me regularly and I have over 30 GB of free space, so running out of disk space is not the problem.

I have been seeing this problem somewhat regularly in both FC5 and FC6.  (Which is currently using 2.8.2.1.)  In fact I can even see the problem before it happens when I see a mailbox that has all of the new messages doubled up.  When I quit out of evolution and check the actual mailbox, there's only one copy of each message.  If I don't quit out of evolution when I see this happen, then I get this error when I clikc on a message.

*** Bug 404842 has been marked as a duplicate of this bug. ***

As a result of this bug I've just lost hundreds of emails, many unread, dating back months and even years. I'm sort of now seriously screwed as a result. Is there any way I can retrieve those lost emails or has Evolution completely wiped them out for good?

jamie, i have never before seen anybody losing emails because of this summary/indexing file bug.

I have never lost previously read emails as a result of this bug, but I have lost unread mail on rare occasions.  

What seems to happen is that on startup, if the pop3 'Fetching Mail' operation finishes before 'Updating Search Folders', then you get the problem.  I have some large mail folders and the indexing takes awhile.  I have never lost mail.

Evolution 1.4 didn't seem to have this problem (for me at least), so I looked at its code and noticed that it didn't fetch the mail on startup.  So I looked in mail/mail-send-recv.c and noticed in mail_autoreceive_init that this code is called at the end:

camel_object_hook_event(mail_component_peek_session(NULL), "online", auto_online, NULL);

I then simply commented that line out and evolution does not perform the Fetching Mail operation on startup, but instead waits until the E_ACCOUNT_SOURCE_AUTO_CHECK_TIME (ie "Automatically check for for new mail every...) is met.  

This to me seems to be reasonable behavior (it is also what 1.4.6 did), but it doesn't really 'fix' the problem properly (ie evo shouldn't fetch mail at all while the indexes are being set up), but since many users will have E_ACCOUNT_SOURCE_AUTO_CHECK_TIME set to 5 or more minutes (and therfore there are 5 or minutes of time for the indexes to get setup), doing this should fix the problem for the vast majority of users.  Attached is a patch.

I have also never lost mail from this bug, but maybe it is because I use the workaround from here (comment from 2006-10-31):
https://launchpad.net/ubuntu/+source/evolution/+bug/27014

Created attachment 83176 [details] [review]
patch to not fetch mail on startup

I should point out that this patch is not heavily tested, and I only use pop3 and mbox.

I have never gotten around to looking at the code as I had once hoped to, so this comment may be totally off base, but is there no mutex associated with the index structures?  If your patch makes the symptom go away, then locking the structures properly should provide a fix.  

What you're saying about the behavior seems correct to me: my mailserver used to be onsite (i.e. the POP was very fast) and I hit this bug constantly.  It was moved to the other end of a WAN link, and I now rarely see the bug.  

*** Bug 408535 has been marked as a duplicate of this bug. ***

Mr. Allan is almost certainly correct. I called this last August. Evo 1's startup concealed the problem, and in 2 when they changed it so that mail was fetched soon enough after startup to collide with other post-startup operations, it was exposed.

You could delay these two operations artificially with a delay (anything is an improvement at this point, and certainly after all these years, my hat is off to any patch at all), but they should be separated from each other properly, with a mutex. 

*** Bug 413363 has been marked as a duplicate of this bug. ***

I have the same problem with 2.8.1.

I start Evo and sometimes while retrieving mail for first time I get this error. Notice that the inbox shows last downloaded message (before the error pop-up) twice.

I usualy fix this closing Evo and starting it again.

This happens in my laptop, but NEVER in the desktop PC, may be it's related to the computer's speed (on a slower machine, more chances to it to happen).

my bug #408535 appears to be the same as this one.
I start evolution soon after boot up, and this error appears....

"Error while Storing folder 'Inbox'"

I have tried the work around (deleting the summary files).
This seems to help temporarily. I tried to run a stack trace(with gdb) before I closed the program. Don't know if its any use? I can email it if required.

*** Bug 419465 has been marked as a duplicate of this bug. ***

*** Bug 422391 has been marked as a duplicate of this bug. ***

I just wanted to say I get this bug too, and I have a very simple Evolution-installation (which I don't use much):

* One account (POP3)
* Only ~100 mails ever sent/received
* Have tried to synchronize with PocketPC using MultiSync in the past.
* I am willing to send any evolution-related file to interested evolution-developers. Just send me a note at anders dot musikka at gmail dot com.

Could the fact that I often go 10 days between checking mail (I use my gmail for most mailing needs), be a contributing factor?

 

Is anyone working on this at all?  This bug has been known for YEARS...

*** Bug 432861 has been marked as a duplicate of this bug. ***

*** Bug 433032 has been marked as a duplicate of this bug. ***

*** Bug 434107 has been marked as a duplicate of this bug. ***

*** Bug 437899 has been marked as a duplicate of this bug. ***

*** Bug 438783 has been marked as a duplicate of this bug. ***

*** Bug 430934 has been marked as a duplicate of this bug. ***

*** Bug 440037 has been marked as a duplicate of this bug. ***

*** Bug 439934 has been marked as a duplicate of this bug. ***

*** Bug 435732 has been marked as a duplicate of this bug. ***

Has everyone a solution for this problem?
My mailbox is growing because i can't clear my trash-folder! 
Now my account is about 1GB and growing ... :-(

*** Bug 433887 has been marked as a duplicate of this bug. ***

http://www.go-evolution.org/FAQ#Why_do_I_get_an_error_.22Summary_and_folder_mismatch.2C_even_after_a_sync.22.3F

*** Bug 443568 has been marked as a duplicate of this bug. ***

*** Bug 443339 has been marked as a duplicate of this bug. ***

now i update my evolution to 2.10 @fedora 7 but the error/problem is the same! :-(

@datensurfer: yes, that's why this bug is still open and not closed.

Is evolution totally unmaintained now?  We've known what the workaround is since 23-Feb-2007 and I proposed a strategy for a fix on that day as well.  Anybody who knows the codebase ought to be able to put a mutex on the index structures in about half a day.  If I knew the codebase, I would do it, but it's a large project and I don't have the familiarity with it that the maintainer (who is?) should, but this should not be hard.

I have been annoyed by thig bug for a very long time, and hit it again this morning (two times this week so war). Yes, there is a workaround, but I had some hope that the frequency and severity of this bug would have lead to a fix much sooner than that, especially given the fact that Dave has shown that the fix is just probably putting a proper mechanism to protect the structure (i.e. mutex), or at least refrain from retrieving mail at startup while the summary is being touched. Is there something not obvious about this bug that I'm just missing?

evolution is not unmaintained, new contributors and patches are always welcome. dave, willing to come up with a patch? this bug here also happens to me without fetching mail on start-up, so i don't think that the attached patch in comment 155 fixes the entire issue... not that i'm not a developer. :-/

oops... should have been "note that" and not "not that".

ok, can everybody say me WHAT is the workaround?
I will only clear my trash-folder, because this is crowing with spam and old messages, but my harddisk has not unlimited space! :-(
If the workaround works, it's ok for me!

Is there any kind of policy about what's considered a "stable release" - ala: 

http://www.gnome.org/projects/evolution/download.shtml

Does it involve the bug database in any way? i.e., no "urgent" or "major" bugs?

I would never say a bad word to people for not doing something for free. Hey, I didn't fix this bug either, and it's been open here for six years. But it doesn't take any work to simply _not_ make claims about stability. 

Hey, too bad - if Gnome doesn't have a stable email client (or it has a gonzo policy about deciding what's stable), just be big about it and admit it. Then everyone will be happier. 

I have been using the patch I submitted on 2007-02-23 on Ubuntu Dapper (evo 2.6.1) on my laptop as well as all my user's systems and it has not caused any problems.  Granted, it is not the proper fix (ie it isn't the mutex and only helps on startup), but I have had the error only once since February (not on startup).  Before, I would have the error almost every time I started evolution.

I am not a gnome developer, but this patch *will* help a lot of people until the maintainers can fix this properly.  IMO someone should apply the patch upstream noting that it is only a workaround and that a proper fix will be forthcoming.

an even number, like 2.10.x, is a stable release, and an odd number like 2.11.x is an unstable release. evolution follows the gnome release cycle, available at http://live.gnome.org/TwoPointNineteen . this is just one many bugs, a long outstanding one, of course. i would not call evolution 2.10 unstable, but perhaps our definitions are different... now somebody pass over the bug free software, please. ;-)

datensurfer: The workaround I was talking about is the patch proposed by James Strandboge, which is not a complete fix, but does seem to resolve the case of hitting the bug on evolution startup, which seems to be what a lot of us are hitting.  If you're not hitting the problem on startup, I'm guessing that patch won't help you.  

David Wood I agree with your comment. Any software with errors (bugs) of this severity...
( ie: can render the application unusable until it is closed and restarted )
..is unstable software, and should be disclosed to prospective users as such.
And hopefully doing this would encourage more resources to be channeled towards it.

ok with a long google-session ;-) i found the following hint, and it work's very fine! The error message is away and i can clear my trash-folder! :-)


Here the solution:

Why do I get an error "Summary and folder mismatch, even after a sync"?

If you get an error popup like: "Error while Expunging folder. Error storing `~/.evolution/mail/local/Inbox (mbox)': Summary and folder mismatch, even after a sync.", try removing the corresponding file with the file ending ".ev-summary", in this example you should remove the file "~/.evolution/mail/local/Inbox.ev-summary". For your interest, this is filed as http://bugzilla.gnome.org/show_bug.cgi?id=213072. 

(datensurfer, your question was answered directly by sven here at this page a few days before.)

i can tell you that two people currently work on a rewrite of these code areas that should also fix this issue.

Dave: Stable Release doesn't necessarily infer anything about crashing or not crashing, it infers that the codebase isn't drastically changing (e.g. new features being added, etc) - just like the Linux kernel.

Also, for every single person that has this problem, there are hundreds (if not thousands) that do not. It's not fair to critisize the developers with the assumption that it crashes for everyone all the time (or even that everyone hits this particular bug).

I, for example, have switched to POP 3 months ago with multiple POP accounts, filtering (where filtered mail can potentially overlap as far as which folders the mail gets moved to) as well as a few vfolders and I have still not seen this bug.

I've even expunged my INBOX while send&receive was fetching mail from one or more accounts and STILL have not been able to recreate this.

I just feel you're being a bit harsh.

OK. You have a perfectly good definition for stable. Only problem: I think you know if you take a poll of people _at large_, they think stable means something else. "Doesn't crash," "doesn't lose data," etc. 

There is only one argument against this point: just put up a web poll somewhere. "What does stable mean to you?" then send the results. Go ahead.

Don't think for a minute I'm arguing that your definition of stable is "wrong" somehow - it's perfectly fine. It's just that it's not the _common_ use. Just a word of advice: when communicating with the public at large, if you intend the less common meanings of words like "stable" next to your software downloads, clarify it with a big red disclaimer. Why make trouble and angst you can easily avoid?

It's perfectly obvious to us the bug is intermittent. I don't think you're really suggesting we've asserted otherwise. We all know intermittent data loss bugs are far worse than if a system never works at all.

I set the bar pretty low. I just wouldn't call my app's release stable if I didn't have, and properly use, a bug database, or it had any Urgent major bugs open on it. That's just good karma. 

Harsh is losing your email to a known bug and then hearing about an alternate, more esoteric definition for "stable."  :) 

> It should be trivial for someone familiar with the sources to verify by code
> inspection that Evo handles disk-full conditions properly.

just committed a fix for this (which basically amounts to calling fsync() before close() and aborting the append if fsync() returns -1)

part of revision 7812

I had been checking that the CamelFolder gets locked (and mutex locked) when appending a message (it does), so I'm not sure if there is actually any race condition or not. I didn't find any proof of such a problem, at least.

One thought I had was that maybe multiple threads were calling camel_store_get_folder() for the same folder name simultaniously and that maybe multiple CamelFolder objects for a particular folder name were being instantiated because of a race... thus causing problems if multiple threads, all with different instances of a CamelFolder object referring to the same on-disk mbox, tried to append/etc at the same time.

turns out not true/possible (afaict) because of the camel_object_bag_*() safeguards in camel-store.c:camel_store_get_folder()

also, initial indexing happens at CamelFolder instantiation time, so it should not even be possible for a second thread to be appending messages to a CamelFolder while it is indexing at startup (since there is no way for a second thread to even get a reference to the CamelFolder instance until it finishes indexing).

you can see that initial indexing happens in camel-local-folder.c:camel_local_folder_construct() which gets called by the various subclasses of CamelLocalFolder when they are instantiated.


I dunno, I give up. I can't find this "locking problem" (if that is what it is). Thankfully I'm no longer a paid evo developer (I'm just a user, so any time I spend hacking on Evolution is out of my personal free time, not my paid time)


If someone can do the research and find the problem, I'll be glad to fix it but my personal free time is as valuable to me as it is to you guys and I don't want to spend countless hours trying to find a bug that doesn't affect me :\


I will volunteer my free time toward answering any questions you guys may have while digging thru evolution-data-server/camel/ source code, tho. Keep in mind that I can't promise I'll be able to answer all questions, my "expertise" is quickly fading as I haven't really hacked on evolution for over 2 years now...

probably best to send questions to the evolution-hackers@gnome.org mailing-list... I'm subscribed and generally watch for camel/mailer questions.

for the records:
http://svn.gnome.org/viewcvs/evolution-data-server/trunk/camel/providers/local/camel-mbox-folder.c?r1=7812&r2=7811

(In reply to comment #200)
> for the records:
> http://svn.gnome.org/viewcvs/evolution-data-server/trunk/camel/providers/local/camel-mbox-folder.c?r1=7812&r2=7811
> 

Andre, does it mean it could have been fixed in svn?

my comment just provided the link for comment 198, for better reference

Peteris: No, I don't think the issue is resolved - my patch just made appending to an mbox slightly more robust in the off-chance that not fsync()ing was a problem.

Note that this error condition is likely the symptom of multiple problems - you'll notice that in the first few years, Michael Zucchi and I fixed several issues that likely caused this same error dialog, but now that those are fixed and the error dialog still pops up, it suggests there are other places that need tweaking. Just that no one seems to know where they are...

I believe that now, the "maybe it doesn't handle disk-full errors well" problem is resolved (maybe?) but that if there is a race condition somewhere as far as indexing&receiving mail at startup, that problem is probably not fixed.

It seems that the majority of the people reporting this bug are getting it without a full disk, so my assumption is that "disk full" was not the main cause of this problem.

Interesting info for those who wish to attempt to fix this issue:

http://www.go-evolution.org/Camel.Local

Mbox bugs

There is a rather nasty bug that crops up from time to time whereby the "index and summary mismatch even after sync". That is because the sync process doesn't perform a full synchronisation, it only checks for the presence of messages in the summary. Ones that are missing are not properly updated. The CamelDS.Local disksummary branch version fixes this with all new algorithms.

*** Bug 445644 has been marked as a duplicate of this bug. ***

Jeffrey, thanks for the info.  That's good stuff.  Do you happen to know if the changes in the disksummary branch are scheduled for inclusion in 2.12 ?  (Am I correct in reading the comments to say that this bug has been fixed by that work?)  Andre, I also noticed your inclusion of this bug in your list of "those ten issues" that should be a priority for 2.1x, so thank you for keeping it on people's radar.  

Dave: I'm sad to say that I don't think it's scheduled as part of 2.12 (but I'm not a developer anymore and don't know for certain).

Part of the problem is that the disk-summary branch was pretty much abandonded when Michael Zucchi left the company a few years ago because he was the only person who knew the direction of that branch and when he left, pretty much all the knowledge about that branch left with him :(

My purpose for mentioning that branch is that perhaps someone could look at that code and figure out how the new algorithms worked and maybe port them back to the trunk branch.

Jeffrey: That is unfortunate, but at least he does state clearly what he believes the problem is:

"the sync process doesn't perform a full synchronisation, it only checks for the presence of messages in the summary. Ones that are missing are not properly updated"

Anybody attempting to fix it now has a good starting place.

His problem statement also explains what looked like an inconsistency beteween turning off mailcheck at startup resolving many of the appearances of the bug and your not finding a locking problem in the code.

agreed, it is definitely a good starting point (and the best lead we have so far)

*** Bug 447016 has been marked as a duplicate of this bug. ***

Not sure if it helps or if it's just noise, anyway:

I was experiencing this with 2.8.x and still with 2.10.x in my "Sent" folder. I just backed up the Sent.ev-summary file and started evo again. This file was recreated and the bug dissapeared.

I still have the backup. If it helps, I can send it privately to some fellow hacker. Don't hesitate to ask.

*** Bug 450486 has been marked as a duplicate of this bug. ***

*** Bug 450938 has been marked as a duplicate of this bug. ***

*** Bug 452101 has been marked as a duplicate of this bug. ***

*** Bug 454089 has been marked as a duplicate of this bug. ***

*** Bug 457335 has been marked as a duplicate of this bug. ***

*** Bug 458450 has been marked as a duplicate of this bug. ***

*** Bug 458811 has been marked as a duplicate of this bug. ***

*** Bug 461443 has been marked as a duplicate of this bug. ***

*** Bug 462945 has been marked as a duplicate of this bug. ***

*** Bug 464085 has been marked as a duplicate of this bug. ***

*** Bug 464264 has been marked as a duplicate of this bug. ***

*** Bug 468441 has been marked as a duplicate of this bug. ***

*** Bug 467973 has been marked as a duplicate of this bug. ***

Maybe this is a naiv idea:

Could this error have something to do with encoding? Maybe the error is located in a library used by evolution (since it comes back since 6 years now)?


Everything went fine for years using evolution. After joining a german mailing list, I recieved an email containing a character, that evolution was not able to display in the subject (first time this happend, since I have lots of fonts and locales installed and I am german).

From that point I got this error. First concerning my mail folder conaining the mails from that list, than, after deleting this mail, concerning the trash folder.

The character is printed correct, when I open the Mail for reading by double click, but in the list view (the character is part of the subject) it is corupted. The char is:

Ž

Mail was written on Mac, using thunderbird 2.0.
There is one thing strange (maybe to me only), this header:

From: =?UTF-8?B?UmVuw6nCjiBLb2NraXNjaA==?= <somoone@somewhere.de>


As I said, naiv maybe.

Changed to thunderbird, since I need a rock solid mailer :-(

*** Bug 470839 has been marked as a duplicate of this bug. ***

*** Bug 470713 has been marked as a duplicate of this bug. ***

*** Bug 472486 has been marked as a duplicate of this bug. ***

*** Bug 472474 has been marked as a duplicate of this bug. ***

*** Bug 474772 has been marked as a duplicate of this bug. ***

*** Bug 475686 has been marked as a duplicate of this bug. ***

is there anyone working on this bug? it's really annoying.

I wouldn't hold my breath.... So far there has been 232 comments covering more than 6 years.. 

Today I switched to Thunderbird...no problems so far!

Nope. No one is working on it.

Jeff Stedfast came the closest above a few months ago and has left some good clues for anyone else who'd like to try. I have long since stopped using Evolution for real work, and I recommend to everyone to do the same. 

I'd say it's fine to never fix the bug, but if I were Gnome's maintainers I would stop actively claiming the email client is OK, and start warning people that it's not OK. Who knows, then maybe someone might even feel like fixing it? 

Refusing to put up disclaimers or warnings is IMO is a foolish and needless breach of ethics. 

I have came across the bug twice this week (using Evolution 2.10.1). I use 5 different mail accounts, I have tons of email and most of them contain foreigh characters as well (mostly french).

It's sad because it seems there is a discrepancy between the perception of users like me (I can see I'm not the only one in that case) that feel this bug is MAJOR and really annoying and preventing Evolution to pretend it is stable, and the perception of the developers or bug dispatchers who don't bother much with it or say it's minor or non reproducible (it must be given the numbers of clones that are tagged each week)...

I would MUCH rather use Evolution than Thunderbird because of its better integration with Gnome overall, but I will be forced to leave like many others if the bug still persists.

(In reply to comment #225)
> Maybe this is a naiv idea:
> 
> Could this error have something to do with encoding? Maybe the error is located
> in a library used by evolution (since it comes back since 6 years now)?
> 
> 
> Everything went fine for years using evolution. After joining a german mailing
> list, I recieved an email containing a character, that evolution was not able
> to display in the subject (first time this happend, since I have lots of fonts
> and locales installed and I am german).

*** Bug 481239 has been marked as a duplicate of this bug. ***

This bug started happening for me just recently. I was running on laptop battery which died and my machine crashed while Evolution was open. When I rebooted and logged back in, my emails had been duplicated with the "Summary and folder mismatch, even after a sync" error constantly appearing. I now can't even write an email without it popping up all the time. 
Each time I close Evolution and reopen it, it says "Storing folder...", takes half an hour to do this, and when it comes back up all the messages since the last time  I started Evolution have been duplicated again. 
Just now I went thru and deleted all the duplicate entries, closed then deleted the ev-summary files, reopened Evolution, and it reduplicated all the messages again, and shows the last lot of emails since I reopened Evolution the previous time as not read, all my junk mail is still there, and the ones I'd marked as important are no longer marked - in other words it is bringing the mail back into my Inbox as if from the beginning. 

What's also interesting is a while ago I had another problem with Evolution, in that I sent a large attached file to someone which bounced back. When it came back to me it was embedded in the body of the message and not as an attached file, and so it kept hanging my machine and I couldn't get into Evolution. I finally managed to get into it but couldn't get to the message to delete it - and so the duplicated entries only go back to this corrupt email and no further.

I'm using Evolution 2.8.1 on Edgy, with only 1 email account.

Hope this helps to debug.

(I think I will be looking elsewhere for other email packages, as the problems I have encountered with Evolution just don't make it worthwhile, they're wasting too much of my time.)

*** Bug 483964 has been marked as a duplicate of this bug. ***

*** Bug 484782 has been marked as a duplicate of this bug. ***

*** Bug 487949 has been marked as a duplicate of this bug. ***

*** Bug 488591 has been marked as a duplicate of this bug. ***

*** Bug 489869 has been marked as a duplicate of this bug. ***

*** Bug 490090 has been marked as a duplicate of this bug. ***

*** Bug 492990 has been marked as a duplicate of this bug. ***

*** Bug 493084 has been marked as a duplicate of this bug. ***

*** Bug 498121 has been marked as a duplicate of this bug. ***

*** Bug 499022 has been marked as a duplicate of this bug. ***

*** Bug 499494 has been marked as a duplicate of this bug. ***

*** Bug 500022 has been marked as a duplicate of this bug. ***

*** Bug 499139 has been marked as a duplicate of this bug. ***

*** Bug 501384 has been marked as a duplicate of this bug. ***

*** Bug 501385 has been marked as a duplicate of this bug. ***

*** Bug 502080 has been marked as a duplicate of this bug. ***

*** Bug 502595 has been marked as a duplicate of this bug. ***

*** Bug 502985 has been marked as a duplicate of this bug. ***

*** Bug 503048 has been marked as a duplicate of this bug. ***

*** Bug 503292 has been marked as a duplicate of this bug. ***

*** Bug 503380 has been marked as a duplicate of this bug. ***

No more problems with 2.12.1 here. Is there someone who can confirm this?

this is still an issue.
there will be a workaround for evolution 2.22.

also see bug 322727

also see http://www.go-evolution.org/Camel.Local#Mbox_bugs

*** Bug 504444 has been marked as a duplicate of this bug. ***

*** Bug 504723 has been marked as a duplicate of this bug. ***

*** Bug 504868 has been marked as a duplicate of this bug. ***

*** Bug 446930 has been marked as a duplicate of this bug. ***

setting gnome target.

*** Bug 507799 has been marked as a duplicate of this bug. ***

*** Bug 508248 has been marked as a duplicate of this bug. ***

Created attachment 102586 [details] [review]
Update the From locations in the summary by reading the mbox

Sankar, I think the patch can work around the issue very well, but few more things  to be done.

* The fd needs to be closed, you close the wrong one IIUC.
* It would be better if you can lock the summary. I really don't want any additions/deletion while your are rebuilding the summary. It can lead to crashes
* Again this needs to be made a func and called at other places the same error happens
* And it should continue the sync after the rebuild and not return with a error.

Otherwise, I think the solution is fine. Rejecting the other patch. Sankar 2.21.90 should feature this.

*** Bug 509800 has been marked as a duplicate of this bug. ***

Created attachment 102975 [details] [review]
Fix

Sankar, looks fine. You can just commit the patch and remove the printf and the total. Or make it debug only. 

I just committed a little improved patch to Trunk: 

http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8374 

I have *not* committed to the stable branch.

Let this bug remain opened for some more time. I will wait for some feedback from  users and for any news of regressions / missed-scenarios (hopefully nothing).

I tested in a summary file that me and Srag corrupted manually (programmatically) and hence will like to hear from someone who is facing this.

Hereafter, Evolution will automatically fix the inconsistencies in the summary by re-setting the spurious from-positions, thus solving the bug. 

I committed something more as well. The additional commit will avoid an
infinite loop that might be caused in cases of corrupt mbox files. 

http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8375 

*** Bug 510990 has been marked as a duplicate of this bug. ***

*** Bug 511272 has been marked as a duplicate of this bug. ***

*** Bug 511903 has been marked as a duplicate of this bug. ***

*** Bug 512223 has been marked as a duplicate of this bug. ***

*** Bug 513288 has been marked as a duplicate of this bug. ***

*** Bug 513516 has been marked as a duplicate of this bug. ***

Setting status to FIXED.
If anybody still runs into similar issues with Evolution 2.21.90 or later, please DO REPORT a bug report (well, the old popup does not exist anymore so people will not know that they should comment to this bug report)!

*** Bug 514610 has been marked as a duplicate of this bug. ***

*** Bug 514676 has been marked as a duplicate of this bug. ***

*** Bug 514719 has been marked as a duplicate of this bug. ***

*** Bug 514731 has been marked as a duplicate of this bug. ***

*** Bug 514853 has been marked as a duplicate of this bug. ***

*** Bug 514963 has been marked as a duplicate of this bug. ***

*** Bug 515061 has been marked as a duplicate of this bug. ***

*** Bug 515394 has been marked as a duplicate of this bug. ***

*** Bug 515711 has been marked as a duplicate of this bug. ***

*** Bug 517174 has been marked as a duplicate of this bug. ***

*** Bug 517921 has been marked as a duplicate of this bug. ***

*** Bug 520219 has been marked as a duplicate of this bug. ***

*** Bug 520359 has been marked as a duplicate of this bug. ***

*** Bug 520350 has been marked as a duplicate of this bug. ***

*** Bug 520545 has been marked as a duplicate of this bug. ***

*** Bug 520907 has been marked as a duplicate of this bug. ***

*** Bug 521830 has been marked as a duplicate of this bug. ***

*** Bug 522145 has been marked as a duplicate of this bug. ***

*** Bug 523339 has been marked as a duplicate of this bug. ***

*** Bug 523615 has been marked as a duplicate of this bug. ***

*** Bug 524514 has been marked as a duplicate of this bug. ***

*** Bug 525399 has been marked as a duplicate of this bug. ***

*** Bug 470839 has been marked as a duplicate of this bug. ***

*** Bug 526302 has been marked as a duplicate of this bug. ***

*** Bug 526733 has been marked as a duplicate of this bug. ***

*** Bug 527004 has been marked as a duplicate of this bug. ***

*** Bug 527296 has been marked as a duplicate of this bug. ***

*** Bug 527390 has been marked as a duplicate of this bug. ***

*** Bug 527720 has been marked as a duplicate of this bug. ***

*** Bug 527908 has been marked as a duplicate of this bug. ***

*** Bug 528863 has been marked as a duplicate of this bug. ***

*** Bug 530764 has been marked as a duplicate of this bug. ***

Hmm. Potential data-loss bug, with the app's most basic functionality: storing mail. "Urgent."

Bug first filed in 2001. ~7 years old. 

Over 130 (!!) dupes. (Thanks, Andre!)

Not sure what this says about Evolution (or Gnome, or perhaps corporate open source in general?) - I stopped using Evo and Gnome long ago (KDE didn't have problems like this). Stayed subscribed out of curiosity. But thank you to all who finally made the fix. 

*** Bug 531989 has been marked as a duplicate of this bug. ***

*** Bug 532149 has been marked as a duplicate of this bug. ***

*** Bug 533968 has been marked as a duplicate of this bug. ***

*** Bug 535997 has been marked as a duplicate of this bug. ***

I am using Ubuntu Desktop 8.04 that includes Evolution 2.22.2. This bug has happened to me twice in the last week, affecting the Inbox each time. I have not tried the workarounds yet so I can't comment if they work or not on my system.

Bruce: Wrong. Can't be the case at all, because the "Summary and folder mismatch" error string does not exist anymore in 2.22. So please be exact about the error you receive, at least your error is definitely not the same issue.

Andre: It's the same error, but with another message right now. Now it is labeled with "Error while storing Inbox" and appears in the lower left corner (status bar). It is no message box any longer. It helps to close evolution, do a rm ~/.evolution/mail/local/Inbox.ev-summary* and start evolution again.
I recommend reopening the bug.

what is the complete, exact error message?

I've run into Error while storing Inbox several times, and that one has nothing to do with any summary files, but with a corrupt mbox file.

Andre: you are correct, my error reporting was not very precise :-(. I have absolutely definitely experienced Inbox problems twice recently, with the **symptoms** being suspiciously similar to those described for this bug. The noticable symptom is that when a Inbox message is selected in the message list panel (that is not the last message in the list), the message text shown in the preview panel is for the subsequent message in the list. Once this occurs, Evolution may be shutdown & restarted indefinitely & the symptom will re-appear. I have never noticed an error message in the status bar (but that does not mean there has not been one). I have never tried the stated workarounds (because the problem has not happened since I first read this bug report). If it ever re-occurs I'll use the built-in Report a Problem links to do so (and hopefully capture some useful diagnostic info in the process).

When this Inbox problem first happened to me, I was using Evolution 2.22.1-0ubuntu3 (hardy). In the last couple of days there have been two Ubuntu updates for Evolution (2.22.2-0ubuntu1.2 and 2.22.2-0ubuntu1.3). After applying these updates I notice that Inbox tasks (deleting items, dragging items to other folders, specifically) are much faster than previously (they used to leave message list entries with strike-through in the Inbox for maybe a minute after deleting / moving an item). Hopefully these updates have a side effect of fixing the other Inbox problems that I had been experiencing.

Maybe your problem is bug 533122. Please put any further comments to that other bug report, because it has definitely nothing to do with this issue here.

(In reply to comment #324)
> what is the complete, exact error message?

Error while Storing folder 'Inbox'

> I've run into Error while storing Inbox several times, and that one has nothing
> to do with any summary files, but with a corrupt mbox file.

Once again, if I delete ~/.evolution/mail/local/Inbox.ev-summary and ~/.evolution/mail/local/Inbox.ev-summary-meta it works again. At the first run after deleting the files evolution shows me "Storing folder 'Inbox' (0%)" up to 100%.
Can't imagine that a corrupt mbox file should be blamed for that. Anyway, can I check this out?

Detected a corrupt mbox file or an invalid 'From' header

The inability to correct this problem has been around since at least FC5 and is now present more than ever in Evolution 3.0. FC9

None of the proposed fixes, i.e. deleting summary files, running the script to automatically do it, restoring from a backup seem to fix the problem. Evolution has become unusable in this latest rendition.

I gave it many years of patience, but I need to have a working/dependable e-mail program.

Funny that in order to post this I had to receive an email, ha ha. Luckily in trying to make this lost cause work, I know more about mail than I ever needed to and therefore could get the message the old fashioned, dependable way.

The folder mis-match was always present since FC5 and could be remedied by closing and restarting, the "Detected a corrupt mbox file or an invalid 'From' header" is new and renders the program useless.

I used to send in the stack traces and everything the evolution team asked for, but they are lost and things have only gotten worse. I'd be happy to return to the program if and when it ever works again, but for now I have better things to do than trying to fix my email program just so I can receive mail.

Paul: What you refer to is bug 533122 which will most probably be fixed in Evolution 2.22.3.

*** Bug 533122 has been marked as a duplicate of this bug. ***

The patch that fixed/put for this is the sole creator of bug #533122. So I would revert the patch in trunk (leave it as such in stable to avoid string break). Instead I have made a fresh patch, that fixes the issue completely.

Here goes my theory and a easy consistent way to reproduce this issue

1. Have a filter <match-all> which copies all mails to a local folder Archive_me
2. Now create an IMAP account, and enable filter inbox in the receiving options.
3. Complete account creation, once you enter the password, etc it starts fetching summaries and after that it copies all the mails in Inbox to the local folder Archive_me. 
4. While it is copying messages to folder Archive_me, go to that folder, double click it, or press F5, couple of times
5. Select a bunch of mail, delete and refresh
6. Expunge mails..
7. Go to 4.

While in 4-7 you will get the summary mismatch or mbox corruption atleast in 5 mins.

Here goes my theory why?

While filtering in ON and it copies messages to the Archive_me folder it holds the folder lock, in append_message. But when we do, refresh folder, 

void
camel_folder_refresh_info (CamelFolder *folder, CamelException *ex)
{
	g_return_if_fail (CAMEL_IS_FOLDER (folder));

	CF_CLASS (folder)->refresh_info (folder, ex);
}

This is called, which doesn't hold any locks or anything or so. I donno why (I'm not the author of the code).

but other functions like expunge, sync holds 

	CAMEL_FOLDER_REC_LOCK(folder, lock);

If you look at what happens for refresh_info for local/mbox folder,

camel_folder_refresh_info->local_refresh_info->camel_local_summary_check->...
->mbox_summary_check->summary_update etc

Which sort of recreates the summary from the mbox file thinking the file became big or so and recreates summary from a mbox file, while the other filtering thread is writing to it, which sort of creates a corruption. 

I was able to reproduce the bug consistently and with the patch, I wasn't getting it for quite some time with a stress environment.

Patch to follow...

Created attachment 113668 [details] [review]
Proposed patch

This fixes it by, while a message is being appended, the refresh->sync/check sort of waits and so avoids the entire issue. 

Patch in comment #333 has been committed to stable and is part of Evolution 2.22.3:
http://svn.gnome.org/viewvc/evolution-data-server/branches/gnome-2-22/camel/camel-folder.c?r1=8564&r2=9068

Not yet committed to trunk.

I regret to say that after experiencing 2.22's instability and occasionally this bug for years, I have given up on Evolution after using it for 7 years, and I have switched to Thunderbird.  Thunderbird has its own set of irritations, but after a month, I can say it's a dramatic improvement over Evolution in terms of stability.  See: http://fourforces.wordpress.com/2008/02/04/setup-mozilla-thunderbird-to-work-with-microsoft-exchange-server/ for a good tutorial on setting it up to work with Exchange using IMAP.  I hope that Evolution can recover; it was way ahead of other email clients in 2001, and Gnome needs a great email client.  I'd gladly share my experience with any Evolution developers who want to understand why Evolution is no longer the right choice for me, and, I suspect, many others.  Andre, what's the best forum for that (since this bug report probably isn't it)?

*** Bug 541011 has been marked as a duplicate of this bug. ***

*** Bug 541341 has been marked as a duplicate of this bug. ***

can you explain how we can repair a broken Inbox in "simple" steps until your patch hits our distributions ? 

Thanks in advance

*** Bug 541856 has been marked as a duplicate of this bug. ***

*** Bug 541897 has been marked as a duplicate of this bug. ***

(In reply to comment #339)
> can you explain how we can repair a broken Inbox in "simple" steps until your
> patch hits our distributions ? 
> 
Im so sorry, there are no simple steps. YOu need to edit the mbox file :( which is tedious if your folder size is hude. Meanwhile, you can give a try at deleteing the summary and starting, 90%cases this should just work.
> Thanks in advance
> 

I confirm that "rm ~/.evolution/mail/local/Inbox.ev-summary" solves the problem for me. (at least temporarly)

I confirm that removing both of these helped me to fix the storing folder error message:
rm ~/.evolution/mail/local/Inbox.ev-summary
rm ~/.evolution/mail/local/Inbox.ev-summary-meta

Committed to trunk for 2.23.5

*** Bug 543027 has been marked as a duplicate of this bug. ***

*** Bug 543126 has been marked as a duplicate of this bug. ***

*** Bug 543420 has been marked as a duplicate of this bug. ***

*** Bug 543951 has been marked as a duplicate of this bug. ***

*** Bug 544378 has been marked as a duplicate of this bug. ***

*** Bug 544379 has been marked as a duplicate of this bug. ***

*** Bug 546258 has been marked as a duplicate of this bug. ***

*** Bug 546453 has been marked as a duplicate of this bug. ***

*** Bug 359841 has been marked as a duplicate of this bug. ***

Lots of dupes here recently, right? I still think this has to do with disk summary. I found another two folders which got newly corrupted. This time I noticed this in the console output:

(evolution:13727): camel-local-provider-WARNING **: Summary doesn't match the folder contents!  eek!
  expecting offset 1522899 got 1523045, state = 2
(evolution:13727): camel-WARNING **: No uid[6744] exists in News&Blogs/Planet GNOME
(evolution:13727): camel-WARNING **: No uid[6746] exists in News&Blogs/Planet GNOME

Created attachment 116080 [details]
Screenshot

Just got this... even if it is not the disk summary, something in 2.23 is doing bad things... the new sqlite perhaps?

Michael, I haven't merged this patch with disk summary,as this approach brought me a deadlock in a situation. I would fix it asap. If you are having 2.22.3.1 it shouldn't happen surely.

(In reply to comment #356)
> Created an attachment (id=116080) [edit]
> Screenshot
> 
> Just got this... even if it is not the disk summary, something in 2.23 is doing
> bad things... the new sqlite perhaps?
new sqlite is for disk summary. Note that if the folder is already corrupted, it wont fix it. My patch avoids any further corruption. But I know it happens in disk summary versions. (2.23.5/6) 

Srinivasa, with 2.22.x I never had any issues. Note that I came to this bug because mine (bug 546453) was marked as a dupe (which I'm not sure it is, given that that this one was opened in 2001).

(In reply to comment #359)
> Note that I came to this bug
> because mine (bug 546453) was marked as a dupe (which I'm not sure it is, given
> that that this one was opened in 2001).

It is because of http://bugzilla.gnome.org/show_bug.cgi?id=213072#c331 .

Michael do you have any article expiration setup in evolution-rss for the folders that got recently corrupted ?

The problem seems related with evolution-rss and db summary.
After performing cleanup (camel_folder_delete_message) I'm doing a camel_folder_expunge which finally triggers camel_mbox_summary_sync_mbox.
THis happens even if nothing gets deleted in the folder.

It think there is a problem with camel_mbox_summary_sync_mbox on camel_mime_parser_step, I've reported something similar (not necessary related to rss folders):
http://bugzilla.gnome.org/show_bug.cgi?id=544731.

@Lucian: Yes, "delete articles older than 30 days". But does this also currupt other mail folders? I've seen corruption also on my Bugzilla mail folder for example.

> But does this also currupt
> other mail folders? I've seen corruption also on my Bugzilla mail folder for
> example.

evolution-rss does not corrupt other mail folders, the behaviour is the same and could happen more frequently on rss folders because of what I just said: camel_folder_expunge is called on folders that have "delete articles ..." activated.

However your bugreport should not be a dup of this, but of #544731 and should block #543389.

*** Bug 547318 has been marked as a duplicate of this bug. ***

Adding this to the disk-summary tracker just so we don't lose it.

Summary:

The "Summary and folder mismatch" bug has been fixed for 2.21.90 but introduced the "message list out of sync with message preview" bug that has been fixed in stable versions 2.22.3 and 2.22.3.1.
This bug is not fixed in the unstable series (2.23.x) due to the disk summary rewrite.

I have committed fixes for 2.23.90. It should fix most of the cases of summary mismatch. Still looking around to see if anything more left with disk summary version.

*** Bug 545454 has been marked as a duplicate of this bug. ***

This fix has some issues on trunk and Im temporarily reverted it to fix right.

Ok, it should be better in trunk now. I have fixed it and it should work well.

This bug can be reproduced at trunk 2.23.91.
When I config a new account using standard unix mbox spool file, and after send some mails, the error occures again.
I am not so sure which operation causes this mistach.

The error message is:
(evolution:28019): camel-local-provider-WARNING **: Didn't get the next message where I expected (9904) got 0 instead

(evolution:28019): camel-local-provider-WARNING **: Didn't get the next message where I expected (9904) got 0 instead

(evolution:28019): camel-WARNING **: Error storing 'mailbox:/liushuai/INBOX (spool)': Summary and folder mismatch, even after a sync
Saving 1/62 dirty records of INBOX

(evolution:28019): camel-local-provider-WARNING **: Didn't get the next message where I expected (9904) got 0 instead

(evolution:28019): camel-WARNING **: Error storing 'mailbox:/liushuai/INBOX (spool)': Summary and folder mismatch, even after a sync

Shuai,

Is the INBOX already corrupted before or just during the last commit? Either is possible. But if it is already corrupted, nothing much can be done except manual correction.

I use a new account and the completely new evolution version. The INBOX should be normal. Not a corrupted INBOX.
However, this problem can be reproduced on solaris 11 and ubuntu 8.10. 

Awesome, if you can reproduce it.

Can you edit camel-mbox-summary.c and there are two places where this warning gets printed, can you hack to find out which one put it out. If so, I can solve it easily. Thanks.

I can easily reproduce this bug now. And it occures every time.

1 Send a mail to this account: mail -s "subject" liushuai@golf < myfile/mail_file
 
2 Config a new local mail account using file /var/mail/liushuai

3 Start evolution and check the mail to make sure the configuration is right

4 Close evolution

5 send a mail to this account: mail -s "subject" liushuai@golf < myfile/mail_file again

6 Start evolution and the bug reproduced

And the warning printed at 

camel-mbox-summary.c:
1085                         
g_warning("Didn't get the next message where I expected (%d) got %d instead",
                                   (int)info->frompos, (int)camel_mime_parser_tell_start_from(mp));

Sucks, that shouldn't be possible :(

Shuai Liu, can you do onething for me, enable #define d(x) x in that file and get me the debug.

I fixed one part where the uids weren't sorted by from position. Which solved for expunge, trash etc. Lemme see if anything else is missing here. Thanks a lot for your help

I changed #define d(x) /*(printf("%s(%d): ", __FILE__, __LINE__),(x))*/ 
  to      #define d(x) x
and 
1314 line:
 d(printf("Updating header for %s flags = %08x\n", camel_message_info_uid(info), info->info.flags));
to 
 d(printf("Updating header for %s flags = %08x\n", camel_message_info_uid(info), info->info.info.flags));

And 
The output is:
-------------------------------------------------------------------------
Failure for store_db_path : [/var/mail/liushuai/folders.db]
Failure for store_db_path : [/var/mail/liushuai/folders.db]
store_db_path /home/liushuai/.evolution/mail/vfolder/folders.db
folders table succesfully created 
Failure for store_db_path : [/var/mail/liushuai/folders.db]
Checking summary
Folder unchanged, do nothing
performing full summary/sync
Looking at message 45
seeking (45) to 16259

(evolution:5104): camel-local-provider-WARNING **: Didn't get the next message where I expected (16259) got 0 instead
Checking summary
Folder unchanged, do nothing
performing full summary/sync
Looking at message 45
seeking (45) to 16259

(evolution:5104): camel-local-provider-WARNING **: Didn't get the next message where I expected (16259) got 0 instead
Checking summary
Folder unchanged, do nothing
performing full summary/sync
Looking at message 45
seeking (45) to 16259

(evolution:5104): camel-local-provider-WARNING **: Didn't get the next message where I expected (16259) got 0 instead
Making error
evolution-mail-Message: Error occurred while existing dialogue active:
Summary and folder mismatch, even after a sync

Awesome, looks like its not sorted based on from pos. Can you do another thing?

cd .evolution/mail
find . -name "folders.db"
 pick the path fo the folders.db for the spool account.

sqlite3 .evolution/mail/local/folders.db or some other folders.db that points to the spool account. (somthing like mbox/* etc)

$select uid,bdata from <folder name>;
 and paste me the out put.

Created attachment 117382 [details] [review]
Tryout patch

Try with this. I did it for mbox, with assumption that spool is also in the same code path, but it isn't. This should fix spool accounts.

I tested the patch 117382. It works. It worked. Mismatch problem seemed disappearing.

I did the next work here:
liushuai@golf:~/.evolution/mail$ find . -name folders.db
./spool/var/mail/liushuai/folders.db
./vfolder/folders.db
./local/folders.db
./imap/sl221404@mail-apac.sun.com/folders.db

The "local/folders.db" seemed not containing INBOX.
So I entered the directory: ~/.evolution/mail/spool/var/mail/liushuai
and select uid,bdata from INBOX;
the output is:
45|16259
47|16769
91|26831
49|17272
33|10805
93|27340
35|11297
95|27919
100|29685
37|12609
21|6028
81|24795
97|28510
102|30191
39|13961
23|6530
83|25304
99|29099
104|30700
25|7022
1|0
105|31209
85|25813
27|8416
3|502
11|2597
71|22301
87|26322
5|1104
13|3106
29|9811
73|22793
15|3615
7|1596
75|23285
9|2088
17|4194
61|19788
77|23777
19|5526
63|20292
79|24286
65|20796
67|21300
53|17775
69|21809
55|18278
57|18781
41|15265
59|19284
43|15757
31|10303
107|31713

Patch committed. Should be fine in 2.23.91

Feel free to reopn post 2.23.91.

*** Bug 550818 has been marked as a duplicate of this bug. ***

*** Bug 552250 has been marked as a duplicate of this bug. ***

*** Bug 553279 has been marked as a duplicate of this bug. ***

*** Bug 529842 has been marked as a duplicate of this bug. ***

*** Bug 532049 has been marked as a duplicate of this bug. ***

*** Bug 554516 has been marked as a duplicate of this bug. ***

*** Bug 555355 has been marked as a duplicate of this bug. ***

*** Bug 558782 has been marked as a duplicate of this bug. ***

*** Bug 564808 has been marked as a duplicate of this bug. ***

*** Bug 565674 has been marked as a duplicate of this bug. ***

*** Bug 557748 has been marked as a duplicate of this bug. ***

*** Bug 568321 has been marked as a duplicate of this bug. ***

It seems to me this bug (or some sort of another bug with similar symptoms) is still there in 2.24.5, as you can see in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524363

I didn't want to mess with the bugs upstream so didn't try reopening this one.

Hope this helps,

(In reply to comment #396)
> It seems to me this bug (or some sort of another bug with similar symptoms) is
> still there in 2.24.5

Yes, that is bug 550414.

tried to follow steps mentioned under :

http://www.go-evolution.org/FAQ#Why_do_I_get_an_error_.22Summary_and_folder_mismatch.2C_even_after_a_sync.22.3F

but to my surprise ,as mentioned all over the web,and here in FAQ ,i was not able to see the file ending ".ev-summary",though the ".ibex.index" and ".ibex.index.data" were there so tried removing the one mentioned ".ibex.index" [as backup was already taken].

[sawrub@sawrub-xbox local]$ evolution --force-shutdown
Shutting down evolution (Evolution Shell)
Shutting down evolution-data-server-2.26 (Evolution Calendar file and webcal backend / Evolution Addressbook file backend)
Shutting down evolution-alarm-notify (Evolution Calendar alarm notification service)
[sawrub@sawrub-xbox local]$ rm -rf *ibex.index

Had sub-folders to In-box so planned to cleaning the index for them too.

[sawrub@sawrub-xbox local]$ cd Inbox.sbd
[sawrub@sawrub-xbox Inbox.sbd]$ rm -rf *ibex.index

Restarted evolution and it was back in action.
------------------------------------------------------------------
My concern,why was the ".ev-summary" not present in there.  

Please help me fine the answer to this .

It looks like I've hit the same problem with Evolution 2.26.1. However, I think this happened because I have launched two copies of Evolution at the same time.

Evolution message box says:
===================================================================
Error while Storing folder 'GMail.COM'.
Summary and folder mismatch, even after a sync
===================================================================

===================================================================
** (evolution:18829): DEBUG: mailto URL command: evolution %s
** (evolution:18829): DEBUG: mailto URL program: evolution
** (evolution:18829): DEBUG: EI: SHELL STARTUP
** (evolution:18829): DEBUG: EI: mail_read_notify
** (evolution:18829): DEBUG: MAIL SERVER: Count changed: 0
** (evolution:18829): DEBUG: EI: mail_read_notify
** (evolution:18829): DEBUG: MAIL SERVER: Count changed: 0

(evolution:18829): camel-local-provider-WARNING **: Didn't get the next message where I expected (43851547) got 46228039 instead

(evolution:18829): camel-local-provider-WARNING **: Didn't get the next message where I expected (43851547) got 46228039 instead
===================================================================


After several hours of poking around, the following seem to resolve the issue:

===================================================================
evolution --force-shutdown
cp -a .evolution/mail/local evolution-mail-local.backup
find ~/.evolution/mail/local -name '*.cmeta' -exec rm {} \;
find ~/.evolution/mail/local -name '*.ev-summary*' -exec rm '{}' \;
find ~/.evolution/mail/local -name '*.ibex.index*' -exec rm {} \;
sqlite3 .evolution/mail/local/folders.db "delete from 'GMail.COM' where bdata<>0;"
evolution
===================================================================

This seem to force Evolution to re-build it's indexes and "fixes" the issue.
Please note that I am not an Evolution developer and have no idea what and how is stored in the folders.db. All I know is that purging the table corresponding to your mailbox while deleting all indexes forces Evo to re-scan and re-build you mailbox.

NOT RESOLVED.

Over 10 years now, it's latest bug number 692315.