Raising Priority and Severity slightly, because there is (meta) data lost. Not sure how best to start debugging this...

Crap, I just realized Evo did so for a *lot* of folders.

NOTE:  Old labels, set by Evo 2.6 or something, seem to NOT be affected. I still
       have these. Labels assigned with a recent Evo version are lost.

milan rewrote the code for 2.22

There is one possible reasons I can think of:
There was some changes in "quit evo as soon as possible", and I *think* it can cause this, because if you change your user flags on a folder and close application, then save of your changes could be skipped and thus you lose the data. But maybe not.

Just a thought. I will test it and let you know with my results. For your information, when will be fixed bug #317755 then it will be saving your folder changes more often (no excuse for the above thing, I know, but just for you to know it will be better).

Bad, the code looks fine. Can you try one thing for me, please?
Open evolution/mail/mail-component.c and comment line stating
camel_application_is_exiting = TRUE;
and let's see what it will do.

(In reply to comment #4)
> There was some changes in "quit evo as soon as possible", and I *think* it can
> cause this, because if you change your user flags on a folder and close
> application, then save of your changes could be skipped and thus you lose the
> data. But maybe not.

This can not be the reason:

(a) I lost labels in multiple folders.
(b) Including labels I have set days or even weeks ago.
(c) I know about the sync-on-folder-switch. I have been telling users about
    this for years, and personally developed the habit of switching folders
    before closing Evo.

Created attachment 110100 [details] [review]
proposed eds patch

for evolution-data-server;

I think I got it. It was possible that evolution unset all flags because it thought it will generate empty set, but it wasn't true and next start there was found a difference between server and local summary and that was updated.
I changed it in the best way I can think of in actual "design".
(Probably better readable explanation is in the patch itself.)

Sankar, Can you review it with HP ?

GNARG.  So Evo did it again, at least 2 times for me today. Still no clue how to reproduce reliably, though. I guess restarting Evo really often (during my debugging cycles today) helped.

Will have to try the patch...

Yes!  Got that little bugger, finally figured out the exact pattern how to reproduce this reliably. Turns out, there are different issues here.


Steps to reproduce, issue (1):

* Set a label on a previously read msg. Then set that very msg to unread.
* Switch folders forth and back, forcing a sync with the IMAP server.
* Restart Evo.

Result:  The just set label is lost. This affects *only* that one label. No other labels are harmed.

This issue seems to be FIXED by the attached patch. (However, I just did a single, brief test run only here.)


Steps to reproduce, issue (2):

* Prerequisites: Have a few messages with labels set. Be sure to set the
  labels using a *recent* Evo version. For good measure, sync to IMAP server,
  and restart Evo.

* Receive a *NEW* message.
* Mark that just received msg as read.
* Set a label on a different, older, previously received msg.
* Switch folders forth and back, forcing a sync with the IMAP server.
* Restart Evo.

Result:  ALL previously assigned labels (see prerequisites) are LOST. The label just set is the only one to survive.

Also, all labels set by ANCIENT versions of Evo (say, 2.6) are not affected. These are stored in the local summary only. The affected labels are those assigned by a recent Evo version, stored on the IMAP server.

This issue (which actually is the one as per comment 0) is NOT fixed by the attached patch. This issue still remains.

Reliably reproducible using Evo 2.22.1.1 with the patch applied.

Correction. The still OPEN issue (2) is even worse and easier to trigger.

Steps to reproduce:

* Prerequisites: Have a few messages with labels set. Be sure to set the
  labels using a *recent* Evo version. For good measure, sync to IMAP server,
  and restart Evo.

* Receive a *NEW* message.
* Mark that just received msg as read.
* Switch folders forth and back, forcing a sync with the IMAP server.
* Restart Evo.

That's right. There is NO need to assign labels. The difference to comment 10.
It is sufficient to  (a) receive a new mail,  (b) read that mail and  (c) sync back to the IMAP server.  Poof, there go all your labels on restarting Evo.

I was able to reproduce and verify the patch for the first issue.  Karsten tells me the second issue is likely not Evolution's fault.

Patch looks good, Milan.  Commit to trunk and stable.

Committed to trunk. Committed revision 8929.
Committed to gnome-2-22. Committed revision 8930.

I will keep this open and move to NEEDINFO state, until guenther got to figure out whether the issue (2) is a server issue or Evo issue.

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

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!

*sigh*

Turns out the remaining issue (see comment 11) actually is a bug with Dovecot 1.0.x, fixed in 1.1.x

For the records and everyones benefit, there is a workaround for Dovecot 1.0.x to avoid this bug. Change the following setting in dovecot.conf and restart Dovecot.

  mbox_lazy_writes = no


Closing RESOLVED FIXED according to comment 12. The second issue actually is RESOLVED NOTGNOME.