Bug 442926

Restarting evolution or e-d-s did not solve the problem.

As a workaround, to hide the problem, I can do the following:
1. Create a new folder
2. Drag all messages to the new folder
3. Drag all the messages from the new folder back to the original folder

It seems like problem with a summary of the folder. Are there any messages on
the Evolution's console? (In case you run evolution on console and you are able
to reproduce it.)

Maybe it doesn't report problems too loudly. Can you look at Help->Debug Logs
and show all messages, whether you will see there something? I've such a feeling
that it is not stored between sessions, maybe something useful in time of the
issue can be found in ~/.evolution/cache/tmp/mail.log.XXXXXX where XXXXXX is
some unique generated code for each session.

I get one message about a corrupt mbox and a missing From: header.
The messages were kind of off-by-one wrong, so I guess evolution's handling of
missing From: headers needs work..

I recalled it yesterday, at home. It's because of enabled large file support,
your 32bit machine is not ready for such thing yet, we should disable this
feature until it will be really fixed. I'm sorry for inconvenience, that's my fault.

I still have the problem.

evolution-2.22.1-1.fc9.i386

It showed up that the large file support, I was thinking of, is not included in
this evolution release, furthermore, this part is exactly same as in 2.12.x version.

For your case, I would like to suggest to close evolution and remove your
summaries, so it will be recreated on next start (it will start significantly
slower, because downloading necessary info from the server about your messages
in each folder. It has some disadvantages too, because some message flags are
stored only in the summary file, and not on the server (or for local accounts
like POP it's stored only locally (the flags of mails). But anyway, it seems
you've broken your summary files already, so probably no other way to fix it.

First of all run "evolution --force-shutdown", so everything evolution related
will be closed.

Then, if you go to ~/.evolution/mail, there are subdirectories for account
types, like "local", "imap" and so on. In each folder you can see some
.ev-summary files, which you can move somewhere else and let evolution rebuild
it on next start. I would recommend to create a backup of whole ~/.evolution
before any tests, so you will be sure you can go back to previous state in case
something goes wrong. Even more, I would like to suggest to remove also .index
and .cmeta files, so those will be regenerated as well.

I'm not aware of any command or UI option to regenerate indexes/summary files,
unfortunately. One more time, do backup of the folder before playing with files.

I have the same bug, but the workaround does work because if I move the messages
in a new folder and then back, the message that I get back are those that were
displayed before (in the preview pane) not, those that were in the message list.

But the correct emails are those that are in the list, the shown emails are
duplicate of mails found elsewhere in my mailbox.

So after applying the workaround, all the incorrectly displayed emails are lost.

Also, do you use the "message filter" (not sure of the name) and more precisely,
do you have a rule which include the action "stop the processing" (not sure
either for the title). I believe that this may be related (but that is just an
hypothesis).

Thanks andre for the upstream bug reference. The Gnome bug shows that the
upstream developer has some idea about the issue and will produce a patch,
hopefully soon. Closing this as an upstream, we will push the patch to fedora
as soon as there will be released an upstream version with it.