After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 213072 - [Fixed in 2.22.3] Error "Summary and folder mismatch" / Message list mismatch
[Fixed in 2.22.3] Error "Summary and folder mismatch" / Message list mismatch
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.24.x (obsolete)
Other All
: High blocker
: ---
Assigned To: Sankar P
Evolution QA team
evolution[disk-summary]
: 210405 215151 219699 315531 319992 327982 332587 333202 341289 341711 343461 343578 344878 345112 354800 357125 357906 359841 363013 363877 368103 381390 404842 408535 413363 419465 422391 430934 432861 433032 433887 434107 435732 437899 438783 439934 440037 443339 443568 445644 446930 447016 450486 450938 452101 454089 457335 458450 458811 461443 462945 464085 464264 467973 468441 470713 470839 472474 472486 474772 475686 481239 483964 484782 487949 488591 489869 490090 492990 493084 498121 499022 499139 499494 500022 501384 501385 502080 502595 502985 503048 503292 503380 504444 504723 504868 507799 508248 509800 510990 511272 511903 512223 513288 513516 514610 514676 514719 514731 514853 514963 515061 515394 515711 517174 517921 520219 520350 520359 520545 520907 521830 522145 523339 523615 524514 525399 526302 526733 527004 527296 527390 527720 527908 528863 529842 530764 531989 532049 532149 533122 533968 535997 541011 541341 541856 541897 543027 543126 543420 543951 544378 544379 545454 546258 546453 547318 550818 552250 553279 554516 555355 557748 558782 564808 565674 568321 (view as bug list)
Depends on:
Blocks: 327508 327510 543389
 
 
Reported: 2001-10-20 03:39 UTC by Travis Caldwell
Modified: 2013-09-13 01:01 UTC
See Also:
GNOME target: 2.24.x
GNOME version: ---


Attachments
screengrab of error message box (7.74 KB, image/jpeg)
2006-07-19 14:38 UTC, Dave Allan
  Details
screengrab of error message box (11.75 KB, image/jpeg)
2006-07-19 14:38 UTC, Dave Allan
  Details
Attempt at repro case using kill -9 (432 bytes, application/x-shellscript)
2006-09-21 13:35 UTC, Dave Allan
  Details
patch to not fetch mail on startup (726 bytes, patch)
2007-02-23 16:42 UTC, James Strandboge
rejected Details | Review
Update the From locations in the summary by reading the mbox (2.95 KB, patch)
2008-01-11 12:38 UTC, Sankar P
rejected Details | Review
Fix (5.62 KB, patch)
2008-01-16 06:53 UTC, Sankar P
committed Details | Review
Proposed patch (379 bytes, patch)
2008-06-30 05:37 UTC, Srinivasa Ragavan
committed Details | Review
Screenshot (28.92 KB, image/png)
2008-08-07 17:04 UTC, Michael Monreal
  Details
Tryout patch (1.32 KB, patch)
2008-08-26 07:06 UTC, Srinivasa Ragavan
committed Details | Review

Description Travis Caldwell 2001-10-20 03:39:29 UTC
1. run evolution
 2. hit Ctrl-E
 3. Click yes
 4. Dialog appears:
            Error while "Expunging folder":
            Summary and folder mismatch, even after a sync

 5. After clicking OK, evolution seems to work ok, but no messages 
    were expunged.

If more info is needed, pls advise on what needs to be provided.
Comment 1 Not Zed 2001-10-21 19:21:33 UTC
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.
Comment 2 Travis Caldwell 2001-10-24 18:09:57 UTC
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?

Comment 3 Leonard Norrgard 2001-10-26 09:08:38 UTC
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.
Comment 4 Travis Caldwell 2001-10-27 01:28:16 UTC
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.
Comment 5 Steve Murphy 2001-10-29 14:27:57 UTC
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?
Comment 6 Luis Villa 2001-10-29 19:33:00 UTC
*** bug 210405 has been marked as a duplicate of this bug. ***
Comment 7 Not Zed 2001-10-30 03:01:08 UTC
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.
Comment 8 Not Zed 2001-10-30 11:18:32 UTC
Are any of you guys running SMP kernels?
Comment 9 Not Zed 2001-11-14 17:54:36 UTC
I dont know what to do about this bug.  I have no plans on changing
any code to fix it atm.
Comment 10 Luis Villa 2001-11-14 18:23:41 UTC
Move it to 1.0.x; if we get any further information we can look at it
again.
Comment 11 Travis Caldwell 2001-11-16 08:44:25 UTC
Not running SMP. runing 2.2.16-22 RH7.0

I haven't seen this occur again since I rm'ed the .ev-summary
Comment 12 Not Zed 2001-11-21 17:52:50 UTC
Ok, so hopefully its just a corrupt summary not being repaired, i'll
investigate based on that.
Comment 13 Not Zed 2001-12-06 12:02:44 UTC
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.
Comment 14 Eric Nickell 2002-01-10 20:00:11 UTC
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.)
Comment 15 Eric Nickell 2002-01-10 20:13:43 UTC
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?
Comment 16 Eric Nickell 2002-01-10 20:14:36 UTC
BTW, I'm running Evo 1.0 on RH7.1.
Comment 17 Eric Nickell 2002-01-10 22:29:51 UTC
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

Thread 6 (Thread 4101 (LWP 23245))

  • #0 __sigsuspend
    at ../sysdeps/unix/sysv/linux/sigsuspend.c line 45
  • #1 __pthread_wait_for_restart_signal
    at pthread.c line 969
  • #2 pthread_cond_wait
    at restart.h line 34
  • #3 e_msgport_wait
    at e-msgport.c line 198
  • #4 thread_dispatch
    at e-msgport.c line 517
  • #5 pthread_start_thread
    at manager.c line 284

Thread 4 (Thread 2051 (LWP 23241))

  • #0 __sigsuspend
    at ../sysdeps/unix/sysv/linux/sigsuspend.c line 45
  • #1 __pthread_wait_for_restart_signal
    at pthread.c line 969
  • #2 pthread_cond_wait
    at restart.h line 34
  • #3 e_msgport_wait
    at e-msgport.c line 198
  • #4 thread_dispatch
    at e-msgport.c line 517
  • #5 pthread_start_thread
    at manager.c line 284

Thread 3 (Thread 1026 (LWP 23240))

  • #0 __sigsuspend
    at ../sysdeps/unix/sysv/linux/sigsuspend.c line 45
  • #1 __pthread_wait_for_restart_signal
    at pthread.c line 969
  • #2 pthread_cond_wait
    at restart.h line 34
  • #3 e_msgport_wait
    at e-msgport.c line 198
  • #4 thread_dispatch
    at e-msgport.c line 517
  • #5 pthread_start_thread
    at manager.c line 284

Thread 1 (Thread 1024 (LWP 23151))

  • #0 __select
    from /lib/libc.so.6
  • #1 _XlcPublicMethods
    from /usr/X11R6/lib/libX11.so.6
  • #2 _XRead
    from /usr/X11R6/lib/libX11.so.6
  • #3 _XReply
    from /usr/X11R6/lib/libX11.so.6
  • #4 XSync
    from /usr/X11R6/lib/libX11.so.6
  • #5 gdk_flush
    at gdkevents.c line 2291
  • #6 gdk_ic_real_new
    at gdkim.c line 528
  • #7 gdk_ic_new
    at gdkim.c line 674
  • #8 gtk_entry_realize
    at gtkentry.c line 710
  • #9 gtk_marshal_NONE__NONE
    at gtkmarshal.c line 312
  • #10 gtk_signal_real_emit
    at gtksignal.c line 1440
  • #11 gtk_signal_emit
    at gtksignal.c line 552
  • #12 gtk_widget_realize
    at gtkwidget.c line 1655
  • #13 gtk_layout_put
    at gtklayout.c line 261
  • #14 draw
    at htmlembedded.c line 84
  • #15 html_object_draw
    at htmlobject.c line 845
  • #16 draw
    at htmlclue.c line 222
  • #17 draw
    at htmlclueflow.c line 1145
  • #18 html_object_draw
  • #19 draw
    at htmlclue.c line 222
  • #20 draw
    at htmlcluev.c line 333
  • #21 draw
    at htmltablecell.c line 175
  • #22 html_object_draw
    at htmlobject.c line 845
  • #23 draw
    at htmltable.c line 1170
  • #24 html_object_draw
    at htmlobject.c line 845
  • #25 draw
    at htmlclue.c line 222
  • #26 draw
    at htmlclueflow.c line 1145
  • #27 html_object_draw
    at htmlobject.c line 845
  • #28 draw
    at htmlclue.c line 222
  • #29 draw
    at htmlcluev.c line 333
  • #30 draw
    at htmltablecell.c line 175
  • #31 html_object_draw
    at htmlobject.c line 845
  • #32 draw
    at htmltable.c line 1170
  • #33 html_object_draw
    at htmlobject.c line 845
  • #34 draw
    at htmlclue.c line 222
  • #35 draw
    at htmlclueflow.c line 1145
  • #36 html_object_draw
    at htmlobject.c line 845
  • #37 draw
    at htmlclue.c line 222
  • #38 draw
    at htmlcluev.c line 333
  • #39 html_object_draw
    at htmlobject.c line 845
  • #40 html_engine_draw_real
    at htmlengine.c line 3908
  • #41 expose
    at gtkhtml.c line 812
  • #42 gtk_marshal_BOOL__POINTER
    at gtkmarshal.c line 28
  • #43 gtk_signal_real_emit
    at gtksignal.c line 1492
  • #44 gtk_signal_emit
    at gtksignal.c line 552
  • #45 gtk_widget_event
    at gtkwidget.c line 2864
  • #46 gtk_layout_adjustment_changed
    at gtklayout.c line 1113
  • #47 gtk_marshal_NONE__NONE
    at gtkmarshal.c line 312
  • #48 gtk_handlers_run
    at gtksignal.c line 1917
  • #49 gtk_signal_real_emit
    at gtksignal.c line 1477
  • #50 gtk_signal_emit_by_name
    at gtksignal.c line 618
  • #51 gtk_range_adjustment_changed
    at gtkrange.c line 1475
  • #52 gtk_marshal_NONE__NONE
  • #53 gtk_handlers_run
    at gtksignal.c line 1917
  • #54 gtk_signal_real_emit
    at gtksignal.c line 1477
  • #55 gtk_signal_emit_by_name
    at gtksignal.c line 618
  • #56 gtk_layout_size_allocate
    at gtklayout.c line 610
  • #57 size_allocate
    at gtkhtml.c line 850
  • #58 gtk_marshal_NONE__POINTER
    at gtkmarshal.c line 193
  • #59 gtk_signal_real_emit
    at gtksignal.c line 1440
  • #60 gtk_signal_emit
    at gtksignal.c line 552
  • #61 gtk_widget_size_allocate
    at gtkwidget.c line 2496
  • #62 e_scroll_frame_size_allocate
    at e-scroll-frame.c line 708
  • #63 gtk_marshal_NONE__POINTER
    at gtkmarshal.c line 193
  • #64 gtk_signal_real_emit
    at gtksignal.c line 1440
  • #65 gtk_signal_emit
    at gtksignal.c line 552
  • #66 gtk_widget_size_allocate
    at gtkwidget.c line 2496
  • #67 gtk_layout_allocate_child
    at gtklayout.c line 790
  • #68 gtk_layout_size_allocate
    at gtklayout.c line 593
  • #69 size_allocate
    at gtkhtml.c line 850
  • #70 gtk_marshal_NONE__POINTER
    at gtkmarshal.c line 193
  • #71 gtk_signal_real_emit
    at gtksignal.c line 1440
  • #72 gtk_signal_emit
    at gtksignal.c line 552
  • #73 gtk_widget_size_allocate
  • #74 e_scroll_frame_size_allocate
    at e-scroll-frame.c line 708
  • #75 gtk_marshal_NONE__POINTER
    at gtkmarshal.c line 193
  • #76 gtk_signal_real_emit
    at gtksignal.c line 1440
  • #77 gtk_signal_emit
    at gtksignal.c line 552
  • #78 gtk_widget_size_allocate
    at gtkwidget.c line 2496
  • #79 gtk_vbox_size_allocate
    at gtkvbox.c line 273
  • #80 gtk_marshal_NONE__POINTER
    at gtkmarshal.c line 193
  • #81 gtk_signal_real_emit
    at gtksignal.c line 1440
  • #82 gtk_signal_emit
    at gtksignal.c line 552
  • #83 gtk_widget_size_allocate
    at gtkwidget.c line 2496
  • #84 gtk_container_resize_children
    at gtkcontainer.c line 1087
  • #85 gtk_window_move_resize
    at gtkwindow.c line 1856
  • #86 gtk_window_check_resize
    at gtkwindow.c line 1523
  • #87 gtk_marshal_NONE__NONE
    at gtkmarshal.c line 312
  • #88 gtk_signal_real_emit
    at gtksignal.c line 1492
  • #89 gtk_signal_emit
    at gtksignal.c line 552
  • #90 gtk_container_check_resize
    at gtkcontainer.c line 928
  • #91 gtk_container_idle_sizer
    at gtkcontainer.c line 847
  • #92 g_idle_dispatch
    at gmain.c line 1367
  • #93 g_main_dispatch
    at gmain.c line 656
  • #94 g_main_iterate
    at gmain.c line 877
  • #95 g_main_run
    at gmain.c line 935
  • #96 gtk_main
    at gtkmain.c line 524
  • #97 bonobo_main
    at bonobo-main.c line 283
  • #98 main
  • #99 __libc_start_main
    at ../sysdeps/generic/libc-start.c line 129

Comment 18 israel 2002-02-01 18:42:19 UTC
*** bug 219699 has been marked as a duplicate of this bug. ***
Comment 19 israel 2002-02-05 23:10:51 UTC
*** bug 215151 has been marked as a duplicate of this bug. ***
Comment 20 Not Zed 2002-02-07 00:46:57 UTC
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?
Comment 21 dd 2002-04-17 18:46:38 UTC
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
Comment 22 Gerardo Marin 2002-04-17 19:02:46 UTC
I've seen some reports of NFS locking on mailboxes not working
properly:  see bug 205095. 
Comment 23 Not Zed 2002-06-19 06:36:09 UTC
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.
Comment 24 Not Zed 2002-06-19 10:27:12 UTC
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.

Comment 25 Not Zed 2002-07-01 02:21:03 UTC
Most of this has been fixed in head, but the changes are too big to
backport.
Comment 26 Not Zed 2002-07-16 01:59:42 UTC
1.0.x is at end of life, so this can be closed since its fixed in 1.1.x
Comment 27 Margarita Manterola 2005-02-17 02:17:33 UTC
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.
Comment 28 Donn Morrison 2005-05-06 00:52:46 UTC
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.
Comment 29 WANG, Xing 2005-05-08 14:57:21 UTC
I ran into this bug too, with evo 2.2.2 + gnome 2.8 on debian unstable.
Comment 30 WANG, Xing 2005-05-08 15:07:09 UTC
Deleted ~/.evolution/mail/local/Inbox.ev-summary and evo seems to have recovered.
Comment 31 Not Zed 2005-09-09 06:22:39 UTC
*** Bug 315531 has been marked as a duplicate of this bug. ***
Comment 32 Ali Akcaagac 2005-09-09 08:10:02 UTC
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.
Comment 33 André Klapper 2005-09-28 12:34:18 UTC
so retargetting that stuff (whou, 1.0.x target milestone - pretty cool)
Comment 34 Ali Akcaagac 2005-10-24 15:26:08 UTC
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.
Comment 35 André Klapper 2005-10-30 12:55:46 UTC
*** Bug 319992 has been marked as a duplicate of this bug. ***
Comment 36 André Klapper 2005-11-25 00:14:12 UTC
reassigning stuff that has been assigned to notzed. goodbye, dude. :-/
Comment 37 André Klapper 2005-11-26 19:50:53 UTC
still in 2.5.2
Comment 38 Karsten Bräckelmann 2006-01-21 18:19:29 UTC
*** Bug 327982 has been marked as a duplicate of this bug. ***
Comment 39 Karsten Bräckelmann 2006-01-21 18:23:13 UTC
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.
Comment 40 André Klapper 2006-02-26 19:18:11 UTC
*** Bug 332587 has been marked as a duplicate of this bug. ***
Comment 41 Daniel Holbach 2006-03-03 14:26:27 UTC
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."
Comment 42 André Klapper 2006-03-03 17:53:05 UTC
*** Bug 333202 has been marked as a duplicate of this bug. ***
Comment 43 Leigh Purdie 2006-03-13 23:39:45 UTC
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 44 Daniel Holbach 2006-03-20 16:57:05 UTC
Comment from Ubuntu bug: "After about a week the same error was back, even when the Evolution-Beagle connector wasn't installed"
Comment 45 André Klapper 2006-03-22 00:51:22 UTC
very annoying, retargetting to 2.7
Comment 46 Sebastien Bacher 2006-03-23 15:09:18 UTC
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?"
Comment 47 Quim Gil 2006-03-24 05:53:12 UTC
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.
Comment 48 Joël Bourquard 2006-03-24 13:31:16 UTC
** 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 ?
Comment 49 Simon Cadieux 2006-04-25 21:03:11 UTC
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.
Comment 50 Jeffrey Stedfast 2006-04-26 14:14:33 UTC
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.
Comment 51 Jason Grant 2006-05-02 10:23:15 UTC
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.
Comment 52 Jeffrey Stedfast 2006-05-02 12:47:19 UTC
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.
Comment 53 André Klapper 2006-05-10 20:27:06 UTC
*** Bug 341289 has been marked as a duplicate of this bug. ***
Comment 54 Jason Grant 2006-05-12 13:11:56 UTC
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)]

Thread NaN (LWP 7389)

  • #0 camel_mbox_summary_sync_mbox
    at camel-mbox-summary.c line 885
  • #1 spool_summary_sync_full
    at camel-spool-summary.c line 169
  • #2 spool_summary_check
    at camel-spool-summary.c line 331
  • #3 camel_local_summary_check
    at camel-local-summary.c line 268
  • #4 local_refresh_info
    at camel-local-folder.c line 476
  • #5 camel_folder_refresh_info
    at camel-folder.c line 298
  • #6 refresh_folder_refresh
    at mail-ops.c line 1584
  • #7 mail_msg_received
    at mail-mt.c line 570
  • #8 thread_dispatch
    at e-msgport.c line 974
  • #9 start_thread
    from /lib/libpthread.so.0
  • #10 clone
    from /lib/libc.so.6
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     {
Comment 55 Jeffrey Stedfast 2006-05-12 14:34:01 UTC
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).

Comment 56 André Klapper 2006-05-14 14:18:28 UTC
*** Bug 341711 has been marked as a duplicate of this bug. ***
Comment 57 Wolf Halton 2006-05-21 21:54:13 UTC
Well that helps.  I guess I got to go find when 2.7 release is planned.  
Comment 58 Albert Cahalan 2006-05-30 03:53:40 UTC
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)
Comment 59 Leigh Purdie 2006-05-30 04:13:20 UTC
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.
Comment 60 André Klapper 2006-05-31 02:36:49 UTC
*** Bug 343461 has been marked as a duplicate of this bug. ***
Comment 61 Wolf Halton 2006-05-31 03:15:15 UTC
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.
Comment 62 Jeffrey Stedfast 2006-05-31 13:32:46 UTC
you need to paste the entire log or it's useless

still can't find this bug :\
Comment 63 Jason Grant 2006-05-31 14:33:06 UTC
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...
Comment 64 Jeffrey Stedfast 2006-05-31 14:36:25 UTC
I don't follow... what kind of account setup do you have?
Comment 65 Wolf Halton 2006-05-31 14:53:14 UTC
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?
Comment 66 Jeffrey Stedfast 2006-05-31 18:59:57 UTC
use: valgrind --tool=memcheck --alignment=8 --error-limit=no --num-callers=16 --log-file=evo.log evolution

attach evo.log.<pid>
Comment 67 Wolf Halton 2006-05-31 23:42:13 UTC
the log file keeps coming up empty, but at least it isn't running a display on the terminal
Comment 68 Leigh Purdie 2006-06-01 01:35:54 UTC
(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.
Comment 69 Jason Grant 2006-06-01 04:33:21 UTC
(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.
Comment 70 André Klapper 2006-06-01 11:18:32 UTC
*** Bug 343578 has been marked as a duplicate of this bug. ***
Comment 71 Jeffrey Stedfast 2006-06-01 15:01:44 UTC
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.
Comment 72 rusty 2006-06-02 02:03:35 UTC
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.
Comment 73 Rick Phillips 2006-06-02 06:36:52 UTC
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
Comment 74 Joël Bourquard 2006-06-02 07:54:06 UTC
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
Comment 75 Rick Phillips 2006-06-02 10:53:14 UTC
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
Comment 76 Jeffrey Stedfast 2006-06-02 13:19:34 UTC
going offline doesn't affect local folders
Comment 77 André Klapper 2006-06-14 21:53:53 UTC
*** Bug 344878 has been marked as a duplicate of this bug. ***
Comment 78 Jason Grant 2006-06-15 03:52:58 UTC
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.
Comment 79 Joël Bourquard 2006-06-15 08:25:57 UTC
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.
Comment 80 André Klapper 2006-06-16 18:20:43 UTC
*** Bug 345112 has been marked as a duplicate of this bug. ***
Comment 81 Dave Allan 2006-07-06 15:37:47 UTC
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.
Comment 82 André Klapper 2006-07-18 09:40:14 UTC
fejj, any news?
Comment 83 Peteris Krisjanis 2006-07-18 10:43:12 UTC
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.
Comment 84 Dave Allan 2006-07-19 13:31:04 UTC
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.  
Comment 85 Jeffrey Stedfast 2006-07-19 14:05:27 UTC
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?
Comment 86 Peteris Krisjanis 2006-07-19 14:25:17 UTC
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.
Comment 87 Dave Allan 2006-07-19 14:37:21 UTC
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.
Comment 88 Dave Allan 2006-07-19 14:38:23 UTC
Created attachment 69176 [details]
screengrab of error message box
Comment 89 Dave Allan 2006-07-19 14:38:50 UTC
Created attachment 69177 [details]
screengrab of error message box
Comment 90 Jeffrey Stedfast 2006-07-19 14:58:02 UTC
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).
Comment 91 Dave Allan 2006-07-19 15:03:44 UTC
Inbox does start with From

Comment 92 Dave Allan 2006-07-19 15:09:20 UTC
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.
Comment 93 Dave Allan 2006-07-19 15:22:41 UTC
I had to restart evolution, which cured the problem.  Sorry I couldn't get you any more info.  
Comment 94 Alexander van Loon 2006-07-23 11:31:39 UTC
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?

 
Comment 95 Ali Akcaagac 2006-07-26 10:48:03 UTC
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.
Comment 96 Dave Allan 2006-08-07 14:29:09 UTC
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.  
Comment 97 André Klapper 2006-08-08 22:01:54 UTC
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)
Comment 98 Dave Allan 2006-08-09 01:56:47 UTC
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.  
Comment 99 Dave Allan 2006-08-09 14:21:52 UTC
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.
Comment 100 Jeffrey Stedfast 2006-08-09 15:16:01 UTC
Thanks Dave, your digging is much appreciated.
Comment 101 Tom Bigwood 2006-08-09 18:04:48 UTC
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.

Comment 102 Joël Bourquard 2006-08-09 23:34:31 UTC
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.
Comment 103 Peteris Krisjanis 2006-08-10 10:14:13 UTC
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.
Comment 104 David Wood 2006-08-15 18:50:35 UTC
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...
Comment 105 Peteris Krisjanis 2006-08-16 12:17:52 UTC
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?
Comment 106 Dave Allan 2006-08-25 17:01:28 UTC
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.  
Comment 107 André Klapper 2006-09-08 10:27:23 UTC
*** Bug 354800 has been marked as a duplicate of this bug. ***
Comment 108 Lee Revell 2006-09-13 17:34:52 UTC
Any progress on this?  It's only been known for 5 YEARS...
Comment 109 Wolf Halton 2006-09-13 22:24:35 UTC
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.
Comment 110 Jeffrey Stedfast 2006-09-14 16:05:07 UTC
hehe, that error dialog means it crashed, Wolf ;)
Comment 111 Wolf Halton 2006-09-14 22:17:27 UTC
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..

Comment 112 Lee Revell 2006-09-15 14:22:37 UTC
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.
Comment 113 Dave Allan 2006-09-15 15:12:31 UTC
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.
Comment 114 Dave Allan 2006-09-15 20:33:11 UTC
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.
Comment 115 Dave Allan 2006-09-21 13:32:27 UTC
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.
Comment 116 Dave Allan 2006-09-21 13:35:34 UTC
Created attachment 73142 [details]
Attempt at repro case using kill -9

This script was not successful at reproducing the bug.
Comment 117 Lee Revell 2006-09-21 15:19:33 UTC
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.
Comment 118 Dave Allan 2006-09-21 16:27:49 UTC
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
Comment 119 André Klapper 2006-09-25 13:37:53 UTC
*** Bug 357125 has been marked as a duplicate of this bug. ***
Comment 120 André Klapper 2006-09-27 14:04:56 UTC
*** Bug 357906 has been marked as a duplicate of this bug. ***
Comment 121 Sebastian James 2006-09-29 20:26:04 UTC
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.
Comment 122 Lee Revell 2006-09-29 20:33:12 UTC
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.
Comment 123 Sebastian James 2006-09-30 13:10:50 UTC
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.
Comment 124 Dave Allan 2006-10-02 14:05:37 UTC
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.  
Comment 125 David Berg 2006-10-13 19:07:32 UTC
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.
Comment 126 Dave Allan 2006-10-13 19:37:15 UTC
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.  
Comment 127 Dave Allan 2006-10-13 19:53:20 UTC
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.  :)
Comment 128 André Klapper 2006-10-19 18:15:55 UTC
*** Bug 363013 has been marked as a duplicate of this bug. ***
Comment 129 Daniel Gryniewicz 2006-10-21 15:47:31 UTC
*** Bug 363877 has been marked as a duplicate of this bug. ***
Comment 130 Matteo Migliavacca 2006-10-22 08:57:10 UTC
I use Evolution 2.6.1 (ubuntu 6.06) and I have that problem every time i enter a sub directory in my inbox.
Comment 131 Mark Robinson 2006-10-22 16:33:58 UTC
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 ?  
Comment 132 Jeffrey Stedfast 2006-10-23 17:19:36 UTC
> 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).
Comment 133 Mark Robinson 2006-10-24 18:59:04 UTC
(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 ?
Comment 134 Jeffrey Stedfast 2006-10-24 20:30:21 UTC
a second send&receive can't start for that particular provider until it is finished
Comment 135 Lee Revell 2006-10-24 20:33:56 UTC
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.
Comment 136 Mark Robinson 2006-10-26 15:45:11 UTC
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
Comment 137 Lee Revell 2006-10-26 15:49:05 UTC
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.
Comment 138 Wolf Halton 2006-10-26 18:19:31 UTC
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.
Comment 139 André Klapper 2006-11-08 17:52:37 UTC
*** Bug 368103 has been marked as a duplicate of this bug. ***
Comment 140 Albert Cahalan 2006-11-28 06:52:38 UTC
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.
Comment 141 André Klapper 2006-12-02 18:37:52 UTC
*** Bug 381390 has been marked as a duplicate of this bug. ***
Comment 142 Øystein Gisnås 2006-12-06 02:23:47 UTC
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.
Comment 143 Sebastian James 2006-12-13 15:03:35 UTC
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.
Comment 144 André Klapper 2006-12-16 17:12:25 UTC
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".
Comment 145 Lee Revell 2006-12-16 19:08:49 UTC
Workarounds are nice, but any idea when this will really be fixed?
Comment 146 Sebastian James 2007-01-14 21:38:06 UTC
My goto rescan hack mentioned in comment #143 doesn't work.
Comment 147 Tres 2007-01-22 15:59:37 UTC
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.
Comment 148 Andrew Wright 2007-01-22 16:29:07 UTC
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.
Comment 149 John Guthrie 2007-02-01 01:48:20 UTC
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.
Comment 150 André Klapper 2007-02-09 01:29:47 UTC
*** Bug 404842 has been marked as a duplicate of this bug. ***
Comment 151 utkjamie 2007-02-20 02:49:44 UTC
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?
Comment 152 André Klapper 2007-02-21 10:25:15 UTC
jamie, i have never before seen anybody losing emails because of this summary/indexing file bug.
Comment 153 Dave Allan 2007-02-21 15:52:48 UTC
I have never lost previously read emails as a result of this bug, but I have lost unread mail on rare occasions.  
Comment 154 James Strandboge 2007-02-23 16:41:07 UTC
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
Comment 155 James Strandboge 2007-02-23 16:42:10 UTC
Created attachment 83176 [details] [review]
patch to not fetch mail on startup
Comment 156 James Strandboge 2007-02-23 16:47:02 UTC
I should point out that this patch is not heavily tested, and I only use pop3 and mbox.
Comment 157 Dave Allan 2007-02-23 18:05:19 UTC
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.  
Comment 158 André Klapper 2007-02-24 12:26:22 UTC
*** Bug 408535 has been marked as a duplicate of this bug. ***
Comment 159 David Wood 2007-02-24 12:38:54 UTC
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. 
Comment 160 André Klapper 2007-03-04 22:59:44 UTC
*** Bug 413363 has been marked as a duplicate of this bug. ***
Comment 161 Juan J. Martinez 2007-03-08 08:48:37 UTC
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).
Comment 162 r.coates 2007-03-17 10:03:04 UTC
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.
Comment 163 André Klapper 2007-03-17 19:39:00 UTC
*** Bug 419465 has been marked as a duplicate of this bug. ***
Comment 164 André Klapper 2007-04-12 19:51:52 UTC
*** Bug 422391 has been marked as a duplicate of this bug. ***
Comment 165 anders musikka 2007-04-22 11:28:38 UTC
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?

 
Comment 166 Lee Revell 2007-04-22 19:50:36 UTC
Is anyone working on this at all?  This bug has been known for YEARS...
Comment 167 André Klapper 2007-04-28 00:34:42 UTC
*** Bug 432861 has been marked as a duplicate of this bug. ***
Comment 168 André Klapper 2007-04-28 01:07:27 UTC
*** Bug 433032 has been marked as a duplicate of this bug. ***
Comment 169 André Klapper 2007-04-30 12:04:54 UTC
*** Bug 434107 has been marked as a duplicate of this bug. ***
Comment 170 André Klapper 2007-05-15 20:26:00 UTC
*** Bug 437899 has been marked as a duplicate of this bug. ***
Comment 171 André Klapper 2007-05-16 14:14:04 UTC
*** Bug 438783 has been marked as a duplicate of this bug. ***
Comment 172 André Klapper 2007-05-18 21:09:26 UTC
*** Bug 430934 has been marked as a duplicate of this bug. ***
Comment 173 André Klapper 2007-05-20 22:57:45 UTC
*** Bug 440037 has been marked as a duplicate of this bug. ***
Comment 174 André Klapper 2007-05-20 23:01:29 UTC
*** Bug 439934 has been marked as a duplicate of this bug. ***
Comment 175 André Klapper 2007-05-21 13:04:41 UTC
*** Bug 435732 has been marked as a duplicate of this bug. ***
Comment 176 datensurfer 2007-05-21 13:16:44 UTC
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 ... :-(
Comment 177 André Klapper 2007-05-24 00:18:17 UTC
*** Bug 433887 has been marked as a duplicate of this bug. ***
Comment 179 André Klapper 2007-06-05 02:47:18 UTC
*** Bug 443568 has been marked as a duplicate of this bug. ***
Comment 180 André Klapper 2007-06-05 02:49:34 UTC
*** Bug 443339 has been marked as a duplicate of this bug. ***
Comment 181 datensurfer 2007-06-05 07:22:07 UTC
now i update my evolution to 2.10 @fedora 7 but the error/problem is the same! :-(
Comment 182 André Klapper 2007-06-05 09:07:31 UTC
@datensurfer: yes, that's why this bug is still open and not closed.
Comment 183 Dave Allan 2007-06-05 12:59:05 UTC
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.
Comment 184 Simon Cadieux 2007-06-05 13:08:36 UTC
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?
Comment 185 André Klapper 2007-06-05 13:32:10 UTC
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. :-/
Comment 186 André Klapper 2007-06-05 13:33:43 UTC
oops... should have been "note that" and not "not that".
Comment 187 datensurfer 2007-06-05 13:41:48 UTC
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!
Comment 188 David Wood 2007-06-05 14:10:03 UTC
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. 
Comment 189 James Strandboge 2007-06-05 14:27:29 UTC
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.
Comment 190 André Klapper 2007-06-05 14:32:03 UTC
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. ;-)
Comment 191 Dave Allan 2007-06-05 18:17:04 UTC
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.  
Comment 192 r.coates 2007-06-06 00:57:20 UTC
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.
Comment 193 datensurfer 2007-06-06 06:57:23 UTC
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. 



Comment 194 André Klapper 2007-06-06 08:41:05 UTC
(datensurfer, your question was answered directly by sven here at this page a few days before.)
Comment 195 André Klapper 2007-06-06 08:41:49 UTC
i can tell you that two people currently work on a rewrite of these code areas that should also fix this issue.
Comment 196 Jeffrey Stedfast 2007-06-06 15:27:15 UTC
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.
Comment 197 David Wood 2007-06-06 15:58:38 UTC
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."  :) 
Comment 198 Jeffrey Stedfast 2007-06-06 21:13:57 UTC
> 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.
Comment 199 Jeffrey Stedfast 2007-06-06 21:50:58 UTC
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.
Comment 201 Peteris Krisjanis 2007-06-07 07:36:42 UTC
(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?
Comment 202 André Klapper 2007-06-07 09:55:37 UTC
my comment just provided the link for comment 198, for better reference
Comment 203 Jeffrey Stedfast 2007-06-07 12:37:21 UTC
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.
Comment 204 Jeffrey Stedfast 2007-06-09 17:36:39 UTC
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.
Comment 205 André Klapper 2007-06-10 17:11:58 UTC
*** Bug 445644 has been marked as a duplicate of this bug. ***
Comment 206 Dave Allan 2007-06-11 14:38:03 UTC
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.  
Comment 207 Jeffrey Stedfast 2007-06-11 14:57:30 UTC
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.
Comment 208 Dave Allan 2007-06-11 17:36:12 UTC
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.
Comment 209 Jeffrey Stedfast 2007-06-11 18:43:32 UTC
agreed, it is definitely a good starting point (and the best lead we have so far)
Comment 210 André Klapper 2007-06-13 11:25:54 UTC
*** Bug 447016 has been marked as a duplicate of this bug. ***
Comment 211 Claudio Saavedra 2007-06-15 15:27:48 UTC
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.
Comment 212 André Klapper 2007-06-24 09:39:12 UTC
*** Bug 450486 has been marked as a duplicate of this bug. ***
Comment 213 André Klapper 2007-06-28 12:51:25 UTC
*** Bug 450938 has been marked as a duplicate of this bug. ***
Comment 214 André Klapper 2007-06-29 13:27:46 UTC
*** Bug 452101 has been marked as a duplicate of this bug. ***
Comment 215 André Klapper 2007-07-05 23:10:27 UTC
*** Bug 454089 has been marked as a duplicate of this bug. ***
Comment 216 André Klapper 2007-07-16 22:25:50 UTC
*** Bug 457335 has been marked as a duplicate of this bug. ***
Comment 217 André Klapper 2007-07-20 19:26:09 UTC
*** Bug 458450 has been marked as a duplicate of this bug. ***
Comment 218 André Klapper 2007-07-21 01:43:18 UTC
*** Bug 458811 has been marked as a duplicate of this bug. ***
Comment 219 André Klapper 2007-07-29 16:08:07 UTC
*** Bug 461443 has been marked as a duplicate of this bug. ***
Comment 220 André Klapper 2007-08-03 09:34:47 UTC
*** Bug 462945 has been marked as a duplicate of this bug. ***
Comment 221 Susana 2007-08-06 19:59:13 UTC
*** Bug 464085 has been marked as a duplicate of this bug. ***
Comment 222 André Klapper 2007-08-08 15:41:48 UTC
*** Bug 464264 has been marked as a duplicate of this bug. ***
Comment 223 André Klapper 2007-08-20 10:07:14 UTC
*** Bug 468441 has been marked as a duplicate of this bug. ***
Comment 224 Srinivasa Ragavan 2007-08-22 10:54:37 UTC
*** Bug 467973 has been marked as a duplicate of this bug. ***
Comment 225 Sebastian Rose 2007-08-29 11:35:05 UTC
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 :-(
Comment 226 André Klapper 2007-09-03 09:03:49 UTC
*** Bug 470839 has been marked as a duplicate of this bug. ***
Comment 227 André Klapper 2007-09-03 09:14:26 UTC
*** Bug 470713 has been marked as a duplicate of this bug. ***
Comment 228 André Klapper 2007-09-03 09:59:47 UTC
*** Bug 472486 has been marked as a duplicate of this bug. ***
Comment 229 André Klapper 2007-09-03 10:00:05 UTC
*** Bug 472474 has been marked as a duplicate of this bug. ***
Comment 230 André Klapper 2007-09-10 11:27:09 UTC
*** Bug 474772 has been marked as a duplicate of this bug. ***
Comment 231 André Klapper 2007-09-11 12:09:24 UTC
*** Bug 475686 has been marked as a duplicate of this bug. ***
Comment 232 Felix Schuster 2007-09-18 18:48:59 UTC
is there anyone working on this bug? it's really annoying.
Comment 233 Bert Pittman 2007-09-18 19:30:14 UTC
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!
Comment 234 David Wood 2007-09-18 19:36:11 UTC
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. 

Comment 235 Simon Cadieux 2007-09-18 20:14:00 UTC
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).
Comment 236 André Klapper 2007-10-01 02:26:26 UTC
*** Bug 481239 has been marked as a duplicate of this bug. ***
Comment 237 Angela Porter 2007-10-05 17:28:21 UTC
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.)
Comment 238 André Klapper 2007-10-06 11:05:59 UTC
*** Bug 483964 has been marked as a duplicate of this bug. ***
Comment 239 André Klapper 2007-10-15 23:12:57 UTC
*** Bug 484782 has been marked as a duplicate of this bug. ***
Comment 240 André Klapper 2007-10-18 16:32:57 UTC
*** Bug 487949 has been marked as a duplicate of this bug. ***
Comment 241 André Klapper 2007-10-20 15:34:29 UTC
*** Bug 488591 has been marked as a duplicate of this bug. ***
Comment 242 André Klapper 2007-10-24 21:12:14 UTC
*** Bug 489869 has been marked as a duplicate of this bug. ***
Comment 243 André Klapper 2007-10-25 12:24:05 UTC
*** Bug 490090 has been marked as a duplicate of this bug. ***
Comment 244 Susana 2007-11-03 12:35:18 UTC
*** Bug 492990 has been marked as a duplicate of this bug. ***
Comment 245 Susana 2007-11-04 15:30:13 UTC
*** Bug 493084 has been marked as a duplicate of this bug. ***
Comment 246 André Klapper 2007-11-19 13:27:29 UTC
*** Bug 498121 has been marked as a duplicate of this bug. ***
Comment 247 André Klapper 2007-11-26 15:54:56 UTC
*** Bug 499022 has been marked as a duplicate of this bug. ***
Comment 248 André Klapper 2007-11-26 16:19:43 UTC
*** Bug 499494 has been marked as a duplicate of this bug. ***
Comment 249 André Klapper 2007-11-28 01:07:57 UTC
*** Bug 500022 has been marked as a duplicate of this bug. ***
Comment 250 André Klapper 2007-11-28 10:24:30 UTC
*** Bug 499139 has been marked as a duplicate of this bug. ***
Comment 251 André Klapper 2007-12-04 11:57:57 UTC
*** Bug 501384 has been marked as a duplicate of this bug. ***
Comment 252 André Klapper 2007-12-04 11:58:33 UTC
*** Bug 501385 has been marked as a duplicate of this bug. ***
Comment 253 André Klapper 2007-12-06 20:05:25 UTC
*** Bug 502080 has been marked as a duplicate of this bug. ***
Comment 254 André Klapper 2007-12-09 11:19:19 UTC
*** Bug 502595 has been marked as a duplicate of this bug. ***
Comment 255 André Klapper 2007-12-11 10:25:06 UTC
*** Bug 502985 has been marked as a duplicate of this bug. ***
Comment 256 André Klapper 2007-12-11 14:48:23 UTC
*** Bug 503048 has been marked as a duplicate of this bug. ***
Comment 257 André Klapper 2007-12-12 23:01:36 UTC
*** Bug 503292 has been marked as a duplicate of this bug. ***
Comment 258 André Klapper 2007-12-13 12:28:24 UTC
*** Bug 503380 has been marked as a duplicate of this bug. ***
Comment 259 Felix Schuster 2007-12-16 22:55:51 UTC
No more problems with 2.12.1 here. Is there someone who can confirm this?
Comment 260 André Klapper 2007-12-16 23:42:34 UTC
this is still an issue.
there will be a workaround for evolution 2.22.
Comment 261 André Klapper 2007-12-16 23:44:05 UTC
also see bug 322727
Comment 262 André Klapper 2007-12-16 23:54:20 UTC
also see http://www.go-evolution.org/Camel.Local#Mbox_bugs
Comment 263 André Klapper 2007-12-19 14:24:52 UTC
*** Bug 504444 has been marked as a duplicate of this bug. ***
Comment 264 André Klapper 2007-12-20 21:35:15 UTC
*** Bug 504723 has been marked as a duplicate of this bug. ***
Comment 265 André Klapper 2007-12-21 14:18:45 UTC
*** Bug 504868 has been marked as a duplicate of this bug. ***
Comment 266 André Klapper 2007-12-21 14:30:51 UTC
*** Bug 446930 has been marked as a duplicate of this bug. ***
Comment 267 André Klapper 2007-12-29 11:30:51 UTC
setting gnome target.
Comment 268 André Klapper 2008-01-07 12:09:27 UTC
*** Bug 507799 has been marked as a duplicate of this bug. ***
Comment 269 André Klapper 2008-01-09 10:35:23 UTC
*** Bug 508248 has been marked as a duplicate of this bug. ***
Comment 270 Sankar P 2008-01-11 12:38:51 UTC
Created attachment 102586 [details] [review]
Update the From locations in the summary by reading the mbox
Comment 271 Srinivasa Ragavan 2008-01-13 16:44:56 UTC
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.
Comment 272 André Klapper 2008-01-16 02:15:46 UTC
*** Bug 509800 has been marked as a duplicate of this bug. ***
Comment 273 Sankar P 2008-01-16 06:53:41 UTC
Created attachment 102975 [details] [review]
Fix
Comment 274 Srinivasa Ragavan 2008-01-16 08:08:07 UTC
Sankar, looks fine. You can just commit the patch and remove the printf and the total. Or make it debug only. 
Comment 275 Sankar P 2008-01-16 09:59:27 UTC
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. 
Comment 276 Sankar P 2008-01-16 12:36:18 UTC
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 
Comment 277 André Klapper 2008-01-21 12:09:14 UTC
*** Bug 510990 has been marked as a duplicate of this bug. ***
Comment 278 André Klapper 2008-01-22 17:08:09 UTC
*** Bug 511272 has been marked as a duplicate of this bug. ***
Comment 279 André Klapper 2008-01-25 01:11:32 UTC
*** Bug 511903 has been marked as a duplicate of this bug. ***
Comment 280 André Klapper 2008-01-26 15:42:41 UTC
*** Bug 512223 has been marked as a duplicate of this bug. ***
Comment 281 André Klapper 2008-01-30 22:24:27 UTC
*** Bug 513288 has been marked as a duplicate of this bug. ***
Comment 282 André Klapper 2008-01-31 22:34:38 UTC
*** Bug 513516 has been marked as a duplicate of this bug. ***
Comment 283 André Klapper 2008-02-02 16:37:14 UTC
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)!
Comment 284 André Klapper 2008-02-06 09:25:44 UTC
*** Bug 514610 has been marked as a duplicate of this bug. ***
Comment 285 André Klapper 2008-02-06 09:25:51 UTC
*** Bug 514676 has been marked as a duplicate of this bug. ***
Comment 286 André Klapper 2008-02-06 13:49:21 UTC
*** Bug 514719 has been marked as a duplicate of this bug. ***
Comment 287 André Klapper 2008-02-06 13:49:44 UTC
*** Bug 514731 has been marked as a duplicate of this bug. ***
Comment 288 André Klapper 2008-02-07 09:42:53 UTC
*** Bug 514853 has been marked as a duplicate of this bug. ***
Comment 289 André Klapper 2008-02-07 13:41:02 UTC
*** Bug 514963 has been marked as a duplicate of this bug. ***
Comment 290 André Klapper 2008-02-07 20:48:18 UTC
*** Bug 515061 has been marked as a duplicate of this bug. ***
Comment 291 André Klapper 2008-02-09 12:52:20 UTC
*** Bug 515394 has been marked as a duplicate of this bug. ***
Comment 292 André Klapper 2008-02-11 09:00:16 UTC
*** Bug 515711 has been marked as a duplicate of this bug. ***
Comment 293 André Klapper 2008-02-18 11:11:18 UTC
*** Bug 517174 has been marked as a duplicate of this bug. ***
Comment 294 André Klapper 2008-02-22 00:22:01 UTC
*** Bug 517921 has been marked as a duplicate of this bug. ***
Comment 295 André Klapper 2008-03-04 10:31:14 UTC
*** Bug 520219 has been marked as a duplicate of this bug. ***
Comment 296 André Klapper 2008-03-04 22:55:41 UTC
*** Bug 520359 has been marked as a duplicate of this bug. ***
Comment 297 André Klapper 2008-03-04 22:57:03 UTC
*** Bug 520350 has been marked as a duplicate of this bug. ***
Comment 298 André Klapper 2008-03-05 20:09:10 UTC
*** Bug 520545 has been marked as a duplicate of this bug. ***
Comment 299 André Klapper 2008-03-07 12:23:53 UTC
*** Bug 520907 has been marked as a duplicate of this bug. ***
Comment 300 André Klapper 2008-03-11 23:11:33 UTC
*** Bug 521830 has been marked as a duplicate of this bug. ***
Comment 301 André Klapper 2008-03-13 16:07:46 UTC
*** Bug 522145 has been marked as a duplicate of this bug. ***
Comment 302 André Klapper 2008-03-19 13:29:46 UTC
*** Bug 523339 has been marked as a duplicate of this bug. ***
Comment 303 André Klapper 2008-03-20 22:45:29 UTC
*** Bug 523615 has been marked as a duplicate of this bug. ***
Comment 304 André Klapper 2008-03-31 15:30:13 UTC
*** Bug 524514 has been marked as a duplicate of this bug. ***
Comment 305 André Klapper 2008-04-02 23:43:21 UTC
*** Bug 525399 has been marked as a duplicate of this bug. ***
Comment 306 André Klapper 2008-04-04 14:53:40 UTC
*** Bug 470839 has been marked as a duplicate of this bug. ***
Comment 307 André Klapper 2008-04-05 14:45:39 UTC
*** Bug 526302 has been marked as a duplicate of this bug. ***
Comment 308 André Klapper 2008-04-07 17:43:06 UTC
*** Bug 526733 has been marked as a duplicate of this bug. ***
Comment 309 André Klapper 2008-04-08 23:29:53 UTC
*** Bug 527004 has been marked as a duplicate of this bug. ***
Comment 310 André Klapper 2008-04-10 14:32:08 UTC
*** Bug 527296 has been marked as a duplicate of this bug. ***
Comment 311 André Klapper 2008-04-11 01:08:53 UTC
*** Bug 527390 has been marked as a duplicate of this bug. ***
Comment 312 André Klapper 2008-04-12 20:53:04 UTC
*** Bug 527720 has been marked as a duplicate of this bug. ***
Comment 313 André Klapper 2008-04-14 07:54:52 UTC
*** Bug 527908 has been marked as a duplicate of this bug. ***
Comment 314 André Klapper 2008-04-19 11:04:19 UTC
*** Bug 528863 has been marked as a duplicate of this bug. ***
Comment 315 André Klapper 2008-04-30 17:45:59 UTC
*** Bug 530764 has been marked as a duplicate of this bug. ***
Comment 316 David Wood 2008-05-01 12:46:01 UTC
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. 
Comment 317 Susana 2008-05-07 22:30:40 UTC
*** Bug 531989 has been marked as a duplicate of this bug. ***
Comment 318 André Klapper 2008-05-09 21:45:22 UTC
*** Bug 532149 has been marked as a duplicate of this bug. ***
Comment 319 André Klapper 2008-05-20 15:32:33 UTC
*** Bug 533968 has been marked as a duplicate of this bug. ***
Comment 320 Srinivasa Ragavan 2008-06-02 08:01:20 UTC
*** Bug 535997 has been marked as a duplicate of this bug. ***
Comment 321 Bruce Smith 2008-06-10 10:12:24 UTC
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.
Comment 322 André Klapper 2008-06-10 12:58:47 UTC
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.
Comment 323 Felix Schuster 2008-06-10 18:25:54 UTC
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.
Comment 324 André Klapper 2008-06-10 18:49:34 UTC
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.
Comment 325 Bruce Smith 2008-06-14 02:11:55 UTC
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).
Comment 326 Bruce Smith 2008-06-18 07:05:23 UTC
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.
Comment 327 André Klapper 2008-06-18 09:23:08 UTC
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.
Comment 328 Felix Schuster 2008-06-20 20:44:21 UTC
(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?

Comment 329 paul 2008-06-28 00:03:54 UTC
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.
Comment 330 André Klapper 2008-06-28 01:46:20 UTC
Paul: What you refer to is bug 533122 which will most probably be fixed in Evolution 2.22.3.
Comment 331 Srinivasa Ragavan 2008-06-30 05:23:31 UTC
*** Bug 533122 has been marked as a duplicate of this bug. ***
Comment 332 Srinivasa Ragavan 2008-06-30 05:36:34 UTC
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...






Comment 333 Srinivasa Ragavan 2008-06-30 05:37:20 UTC
Created attachment 113668 [details] [review]
Proposed patch
Comment 334 Srinivasa Ragavan 2008-06-30 05:38:38 UTC
This fixes it by, while a message is being appended, the refresh->sync/check sort of waits and so avoids the entire issue. 
Comment 335 André Klapper 2008-06-30 15:53:08 UTC
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.
Comment 336 Dave Allan 2008-06-30 16:55:49 UTC
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)?
Comment 337 André Klapper 2008-07-01 09:08:13 UTC
*** Bug 541011 has been marked as a duplicate of this bug. ***
Comment 338 André Klapper 2008-07-03 09:36:17 UTC
*** Bug 541341 has been marked as a duplicate of this bug. ***
Comment 339 Lionel Dricot 2008-07-07 13:47:16 UTC
can you explain how we can repair a broken Inbox in "simple" steps until your patch hits our distributions ? 

Thanks in advance
Comment 340 André Klapper 2008-07-10 00:02:11 UTC
*** Bug 541856 has been marked as a duplicate of this bug. ***
Comment 341 André Klapper 2008-07-10 00:10:40 UTC
*** Bug 541897 has been marked as a duplicate of this bug. ***
Comment 342 Srinivasa Ragavan 2008-07-10 05:18:54 UTC
(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
> 

Comment 343 Lionel Dricot 2008-07-10 12:23:57 UTC
I confirm that "rm ~/.evolution/mail/local/Inbox.ev-summary" solves the problem for me. (at least temporarly)
Comment 344 vladimir.wsol 2008-07-10 14:11:00 UTC
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
Comment 345 Srinivasa Ragavan 2008-07-12 05:04:40 UTC
Committed to trunk for 2.23.5
Comment 346 André Klapper 2008-07-15 09:40:23 UTC
*** Bug 543027 has been marked as a duplicate of this bug. ***
Comment 347 André Klapper 2008-07-16 16:19:50 UTC
*** Bug 543126 has been marked as a duplicate of this bug. ***
Comment 348 André Klapper 2008-07-17 14:26:56 UTC
*** Bug 543420 has been marked as a duplicate of this bug. ***
Comment 349 André Klapper 2008-07-21 09:41:53 UTC
*** Bug 543951 has been marked as a duplicate of this bug. ***
Comment 350 André Klapper 2008-07-23 20:36:29 UTC
*** Bug 544378 has been marked as a duplicate of this bug. ***
Comment 351 André Klapper 2008-07-23 20:37:18 UTC
*** Bug 544379 has been marked as a duplicate of this bug. ***
Comment 352 André Klapper 2008-08-04 17:16:00 UTC
*** Bug 546258 has been marked as a duplicate of this bug. ***
Comment 353 André Klapper 2008-08-05 19:24:25 UTC
*** Bug 546453 has been marked as a duplicate of this bug. ***
Comment 354 Akhil Laddha 2008-08-06 05:15:07 UTC
*** Bug 359841 has been marked as a duplicate of this bug. ***
Comment 355 Michael Monreal 2008-08-07 09:45:43 UTC
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
Comment 356 Michael Monreal 2008-08-07 17:04:56 UTC
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?
Comment 357 Srinivasa Ragavan 2008-08-07 17:05:27 UTC
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.
Comment 358 Srinivasa Ragavan 2008-08-07 17:08:00 UTC
(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) 

Comment 359 Michael Monreal 2008-08-07 17:19:02 UTC
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).
Comment 360 André Klapper 2008-08-07 17:31:20 UTC
(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 .

Comment 361 Lucian Langa 2008-08-08 05:41:36 UTC
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.



Comment 362 Michael Monreal 2008-08-08 05:56:16 UTC
@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.
Comment 363 Lucian Langa 2008-08-08 08:39:19 UTC
> 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.
Comment 364 André Klapper 2008-08-11 17:39:30 UTC
*** Bug 547318 has been marked as a duplicate of this bug. ***
Comment 365 Matthew Barnes 2008-08-11 17:59:55 UTC
Adding this to the disk-summary tracker just so we don't lose it.
Comment 366 André Klapper 2008-08-17 15:18:37 UTC
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.
Comment 367 Srinivasa Ragavan 2008-08-18 09:30:37 UTC
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.
Comment 368 André Klapper 2008-08-18 13:39:01 UTC
*** Bug 545454 has been marked as a duplicate of this bug. ***
Comment 369 Srinivasa Ragavan 2008-08-19 15:23:45 UTC
This fix has some issues on trunk and Im temporarily reverted it to fix right.
Comment 370 Srinivasa Ragavan 2008-08-20 10:58:05 UTC
Ok, it should be better in trunk now. I have fixed it and it should work well.
Comment 371 Shuai Liu 2008-08-25 07:27:18 UTC
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
Comment 372 Srinivasa Ragavan 2008-08-25 09:18:52 UTC
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.
Comment 373 Shuai Liu 2008-08-25 09:34:48 UTC
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. 
Comment 374 Srinivasa Ragavan 2008-08-25 11:16:34 UTC
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.
Comment 375 Shuai Liu 2008-08-26 03:28:19 UTC
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
Comment 376 Shuai Liu 2008-08-26 03:28:42 UTC
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));
Comment 377 Srinivasa Ragavan 2008-08-26 04:10:34 UTC
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

Comment 378 Shuai Liu 2008-08-26 05:14:47 UTC
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
Comment 379 Srinivasa Ragavan 2008-08-26 07:01:51 UTC
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.

Comment 380 Srinivasa Ragavan 2008-08-26 07:06:01 UTC
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.
Comment 381 Shuai Liu 2008-08-26 08:31:54 UTC
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


Comment 382 Srinivasa Ragavan 2008-08-31 18:16:40 UTC
Patch committed. Should be fine in 2.23.91
Comment 383 Srinivasa Ragavan 2008-09-02 04:51:50 UTC
Feel free to reopn post 2.23.91.
Comment 384 André Klapper 2008-09-04 15:05:55 UTC
*** Bug 550818 has been marked as a duplicate of this bug. ***
Comment 385 André Klapper 2008-09-14 17:43:03 UTC
*** Bug 552250 has been marked as a duplicate of this bug. ***
Comment 386 André Klapper 2008-09-22 17:29:43 UTC
*** Bug 553279 has been marked as a duplicate of this bug. ***
Comment 387 André Klapper 2008-09-28 21:45:05 UTC
*** Bug 529842 has been marked as a duplicate of this bug. ***
Comment 388 André Klapper 2008-09-28 21:45:11 UTC
*** Bug 532049 has been marked as a duplicate of this bug. ***
Comment 389 André Klapper 2008-10-01 11:15:23 UTC
*** Bug 554516 has been marked as a duplicate of this bug. ***
Comment 390 André Klapper 2008-10-07 09:45:21 UTC
*** Bug 555355 has been marked as a duplicate of this bug. ***
Comment 391 André Klapper 2008-11-01 13:20:29 UTC
*** Bug 558782 has been marked as a duplicate of this bug. ***
Comment 392 André Klapper 2008-12-17 04:56:32 UTC
*** Bug 564808 has been marked as a duplicate of this bug. ***
Comment 393 André Klapper 2008-12-27 23:31:32 UTC
*** Bug 565674 has been marked as a duplicate of this bug. ***
Comment 394 André Klapper 2009-01-22 23:27:15 UTC
*** Bug 557748 has been marked as a duplicate of this bug. ***
Comment 395 André Klapper 2009-01-22 23:28:53 UTC
*** Bug 568321 has been marked as a duplicate of this bug. ***
Comment 396 Olivier Berger 2009-04-20 12:37:46 UTC
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,
Comment 397 André Klapper 2009-04-20 12:57:32 UTC
(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.
Comment 398 sawrub 2009-09-27 08:31:04 UTC
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 .
Comment 399 Sergey 2010-04-10 17:52:56 UTC
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.
Comment 400 Mikey 2013-01-25 04:21:41 UTC
NOT RESOLVED.

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