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 559391 - Wrong number of unread mails in folder tree
Wrong number of unread mails in folder tree
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.2.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: Milan Crha
Evolution QA team
evolution[disk-summary] evolution[vfo...
: 541421 588211 591127 621217 658669 659695 683291 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-11-05 09:35 UTC by Christian Stadach
Modified: 2012-09-04 17:13 UTC
See Also:
GNOME target: ---
GNOME version: 3.1/3.2


Attachments
wild guess (2.52 KB, application/zip)
2008-11-20 18:55 UTC, Milan Crha
  Details
eds patch (7.44 KB, patch)
2012-07-04 09:44 UTC, Milan Crha
committed Details | Review

Description Christian Stadach 2008-11-05 09:35:16 UTC
Binary package hint: evolution

Evolution 2.24.1 (2.24.1-0ubuntu2) in Ubuntu 8.10

What you expected to happen:

When new mail is fetched from an imap server or when unread mails are marked as read by simply reading them I expect the number of unread mails in the folder tab to be updated automatically.

What happened instead:

When new emails are fetched from my imap server (german email provider GMX) or when I mark emails as read by reading them, the number of unread mails in my imap folders are not updated.

Occasionaly when I right-click on a folder the number is updated. Sometimes renewing of a folder works, too.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/evolution
Package: evolution 2.24.1-0ubuntu2
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/zsh
SourcePackage: evolution
Uname: Linux 2.6.27-7-generic x86_64
Comment 1 Srinivasa Ragavan 2008-11-06 06:26:05 UTC
Milan can you look at it? Same thing, at time, the folder tree count isnt right. The Info label is always right.
Comment 2 Milan Crha 2008-11-06 09:22:14 UTC
Srag: It depends whether I'm able to reproduce it consistently. If not, then quite hard to try to figure out what's going wrong there.

Christian: I guess, from the description, it happens to you every time, right? Could you test two things for me, please?

a) Mark some messages in some folder as unread, then restart Evolution, and try to reproduce. Did it happen?

b) Close evolution, then run 'evolution --force-shutdown', then move yours ~/.evolution/mail/imap/<account-name>/folders.db to some other directory (do not delete it, just move it somewhere else, so we will be able to put it back later) and then run Evolution. It'll take some time to fetch all the headers from the server first time you run it. When it'll be done, just to be sure, close Evolution and run it again. Try to reproduce your issue. Is it still happening? If no, then there is something wrong with the file we moved out.
Comment 3 Christian Stadach 2008-11-06 22:36:29 UTC
Thanks for the quick reply.

Milan: I did what you told me to do, here are my results.

a) I marked Emails unread in different folders and restarted evolution (by closing the only evolution window open, no kill or anything like that)

After Evolution restarted all folders but the last folder I marked Emails unread where marked with the proper amount of unread emails (the last folder with previously marked as unread emails had no unread emails in it, although I did mark them before.

When trying to read the mails and by that marking them as read the folder view still showed the original amount of unread mails (no decrease of number). 
After reloading the folders a few times, they finaly showed the right amount of emails.

b) Everything is just as before. I already tried to delete the whole <account-name>-folder before and creating a new one, still the same thing.

Hope this helps
Comment 4 Milan Crha 2008-11-07 23:07:06 UTC
It's quite strange behaviour, could you try one more thing, please?

Close evolution, to be sure of clean evo do 'evolution --force-shutdown'
then run evolution from console and try to repeat steps from a).
I believe there will be written some reason on the console.
Comment 5 Christian Stadach 2008-11-10 14:57:25 UTC
Hei Milan,

I did what you said in the last post.

I shut evolution down with option --force-shutdown after marking some messages as unread. After restarting the right amount of emails where shown to be unread. When marking them read again the number doesn't update though.

Could it be that after the update from ubuntu 8.04 to ubuntu 8.10 (during which also the new version of evolution was installed) my old settings weren't properly transfered?

Comment 6 Milan Crha 2008-11-10 15:05:31 UTC
(In reply to comment #5)
> Could it be that after the update from ubuntu 8.04 to ubuntu 8.10 (during which
> also the new version of evolution was installed) my old settings weren't
> properly transfered?

You said it doesn't work even you let recreate your account data from scratch, as you wrote in b) in comment #3. Thus it does quite strange things now.

Once again, what is on the console of Evolution, when you try the a)? Please paste here, but be sure you removed any sensitive data before submitting. Thanks.
Comment 7 Christian Stadach 2008-11-10 16:25:36 UTC
The Console only doesn't give any messages while marking emails unread.

It does however tell me something when I mark emails unread and change the imap folder (Saving 1/*** dirty records of *****)

Comment 8 Christian Stadach 2008-11-11 13:24:07 UTC
Just to rule out the upgrading issues I reinstalled ubuntu 8.10 in a virtual pc and set the email account to the same settings.

Same issues as before, also same console messages
Comment 9 Milan Crha 2008-11-12 09:46:02 UTC
Srag, I wonder whether this has anything to do with this change
http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9229
I fixed the same issue recetny with quite different approach in bug #558737 thus the reason you did the change before is obsolete?
I know the lock was there quite new, it was added in
http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9116
so maybe not related at all.
Comment 10 Srinivasa Ragavan 2008-11-12 15:16:41 UTC
Milan, this is pretty old code. I added for folder summary mismatch and it was wrong and I moved it as a hack to local. It should have nothing to do with it.
Comment 11 matthew jones 2008-11-14 08:45:27 UTC
I too am experiencing this and it is not consistant.  I am using Evolution 2.24.1 with 8.10 and the exchange plugin.  

Most of the time it says I have 1 unread email when in fact I have no unread emails.  But then another email will come in and the problem will be ok once that email is read.

Also the total number of emails reported can be wrong.

It is a bit annoying I use Evolution heavily for work, more than 100 emails a day, I have been extremely happy with it since switching 1 year ago.  

Thanks
Hope it can get sorted.
Comment 12 Christian Stadach 2008-11-14 12:00:14 UTC
Matthew:  Could you maybe test the same things Milan posted in Post #2?

Just to make sure the problem is the same.
Comment 13 matthew jones 2008-11-14 14:23:52 UTC
(In reply to comment #12)
> Matthew:  Could you maybe test the same things Milan posted in Post #2?
> 
> Just to make sure the problem is the same.
> 
Christian,

I did a: marked unread, closed evolution, then opened, and it did correct the count when it re-opened.  This does appear to fix the problem so far.  I will keep trying and inform if this method ever fails.

As for option b: Unfortunately I am a gui Ubuntu user and what is described is a little beyond me.  I am also scared to lose all my precious 1,000's of work emails.

Cheers
Matt
 
Comment 14 Patrick Bauer 2008-11-20 06:25:09 UTC
I can confirm with Christian that I too am having the exact same problems (with the number of messages not updating accurately on the left side -- the tree view -- specifically the inbox -- if for example i deleted a message, the message count will not decrease).

I am also using an IMAP based account -- so it is possible that this is IMAP related.  Problem could also have orginated, when the mail data was converted to the new evolution database format.  This also occured for me when i upgraded from Ubuntu 8.04 to 8.10.

The also annoying thing (possibly more annoying), is that for a *very* short time, new mail notification was working in the gnome notification area, but now, I am not getting any new mail notification flashing in the notification area, when i get new mail.  These two issues could be related somehow.

Pat
Comment 15 Patrick Bauer 2008-11-20 06:53:39 UTC
As a test, i created a new user in Ubuntu.  I exited Evolution completely (with my regular Ubuntu user acount), logged in as the test Ubuntu user, and created a new Evolution account (using the same user IMAP settings as my regular user account -- the one that has the problems).  Guess what ?  New mail notification works in the Gnome notification area, and the message count on the left side (the folder tree) works as it's supposed to.  So I can only conclude that when upgrading Evolution from the Ubuntu 8.04 version to 8.10, there was some kind of "corruption" that went on.  Problem is, i don't know how to fix this, or how to "re-create" my evolution accounts (with the regular Ubuntu user), and transfer all the saved mail in my local saved mail folders, plus transfer all the calendar data, and contacts (if this makes sense).

Pat
Comment 16 Srinivasa Ragavan 2008-11-20 09:08:35 UTC
There is a issue on non updation of counts for IMAP. Is it always? 

I rule out migration, since, I know of few users for whom, it works. AFAIK, there is some particular scenario, when the unread count isn't updated to the folder tree, but updates to the info label. It would be great, if you can find a pattern that could help us. Anyways we will keep trying to reproduce and fix it.
Comment 17 Patrick Bauer 2008-11-20 16:22:32 UTC
hi Srinivasa:

Okay i executed steps a) and b) (as outlined by Milan, in Comment #2), and also ran evolution from the console.

When marking messages as unread, and then restarting evolution:  when evolutions comes back up, those messages that I marked as unread, go back to "read".

I've also noticed that the unread count *does* update in the info label, but *not* in the folder tree.  This happens *every* time.

Moved folders.db to another directory, then restarted evolution (following the shutdown instructions to the letter) -- no change in behavior to the unread count in the folder tree.  Also am not getting new mail notifications in the notification area of the panel.  So i guess we can rule out a corrupted "folders.db".  To me, it seems like new mail notification (where the icon is supposed to be flashing in the notification area of the panel) and the unread count not working in the folder tree, are related some how.

Also ran evolution from the console, and here is what i get:

** (evolution:20961): DEBUG: mailto URL command: evolution %s
** (evolution:20961): DEBUG: mailto URL program: evolution

(evolution:20961): camel-imap-provider-WARNING **: Unable to load summary no such table: Deleted Messages

Saving 1/736 dirty records of INBOX

(evolution:20961): camel-imap-provider-WARNING **: Unable to load summary no such table: Drafts

Saving 2/736 dirty records of INBOX

(evolution:20961): camel-imap-provider-WARNING **: Unable to load summary no such table: Junk


(evolution:20961): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()


Now, creating a test e-mail message, sending it, and clicking send/receive, so that it comes in, and then clicking on the actual e-mail:


(evolution:20961): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(evolution:20961): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
Saving 1/1 dirty records of Sent

(evolution:20961): camel-imap-provider-WARNING **: Unable to load summary no such table: Deleted Messages


(evolution:20961): camel-imap-provider-WARNING **: Unable to load summary no such table: Drafts

Saving 2/737 dirty records of INBOX
Saving 1/737 dirty records of INBOX

(evolution:20961): camel-imap-provider-WARNING **: Unable to load summary no such table: Junk


And then a couple of minutes later, another message on the console:

removing cache for  INBOX 737 0x8cebcf0
done .. now 558


Does this help ?  Not sure if the "dirty records" message means anything.  Also just want to emphasize again that i'm working with IMAP e-mail accounts.  

Let me know if you want me to run any other kind of tests.

Pat
Comment 18 Patrick Bauer 2008-11-20 16:42:23 UTC
hey Guys:

I found the problem.  In my e-mail account preferences, in the "Receiving E-mail" tab, at the "Use Secure Connection" option, i had "TLS" enabled.  I changed this to "No Encryption", and now the unread count in the folder tree, as well as new mail notifications (in the notification area of the panel), work as they should again.

So i'm assuming that this is not a bug with evolution, but my internet service provider not supporting encryption (properly).  I have been told in the past by them that encryption has been a problem with their mail server.

Pat
Comment 19 Patrick Bauer 2008-11-20 16:50:03 UTC
Also, in the same "Receiving E-mail" tab, in the e-mail account preferences, i had to change "Authentication Type" from CRAM-MD5 (which is what it as set at) to "Login".

So in summary, the problem was that in the e-mail account preferences, TLS was enabled (needed to be set to "No Encryption"), and Authentication Type needed to be set to "Login".

Pat
Comment 20 Patrick Bauer 2008-11-20 16:53:04 UTC
Correction:

Authentication Type in the Receiving E-mail Preferences needed to be set to "Password".

Pat
Comment 21 Milan Crha 2008-11-20 18:55:10 UTC
Created attachment 123127 [details]
wild guess

No no no, I cannot reproduce it myself. I tried all the above, deleting messages, marking read/unread, and so on and nothing, works fine on my IMAP server. Here's a wild guess of things I think I'm not correct in eds (various providers) and in eex. But it's so wild that some parts could be wrong for sure.

One thing I'm thinking of, maybe when processing filters, and some fake exception became there, like "no such table", then it stops before the summary is saved. Maybe. I noticed only the summaries for vFolders are finalized dirty, and once I saw on eex, but I've some trouble with my server, thus it could be because of that.

Otherwise no idea here, I'm so sorry. :(
Comment 22 Patrick Bauer 2008-11-20 19:25:45 UTC
hi Milan:

Well either way, my problem has been fixed (by disabling TLS, and going with "No Encryption"), and also changing authentication type to "Password", so it's very possible that the problem could have been on my ISP's end (that encryption, whether it be TLS or SSL, isn't fully supported).

I'm not sure if my solution helps the original poster, Christian Stadach.

Pat
Comment 23 matthew jones 2008-11-21 04:45:59 UTC
I am using the exchange plugin does not help me because I don't have those settings.

Comment 24 Christian Stadach 2008-11-21 06:40:43 UTC
Unfortunatelly Patricks change with the encryption settings did not help me.

Still the same issues

Milan: I am not using any filters, although I am getting the "no such table" info as well, but only on folders which are empty and not with the folders that had a change in count of read/unread emails.

By the way I realized that the "info label" does update when the count of read/unread mails changes.

I agree that we can rule out migration, because I tried installing Ubuntu in a virtual PC and tried making a complete new evolution profile and this issue was still happening.

I'll help where I can, creating a proper scenario. Just tell me what I can do
Comment 25 Srinivasa Ragavan 2008-11-24 03:53:39 UTC
Milan, I think I should take closer look at the patch. Not pushing it for 2.24.2. I can do a dot one, if we are sure, it fixes it. Thanks anyway for the try. I would do it today/tomorrow.
Comment 26 Milan Crha 2008-11-25 12:38:16 UTC
I think some bits are wrong in the attachment of the comment #21, it seems, with that applied, marking more than one message as read in the IMAP account takes awful time to finish. Just take care of it while testing, please.
Comment 27 Fabio Muzzi 2008-11-26 23:14:12 UTC
I can confirm that this bug also affects me. To update unread message count for a folder I have to right-click the folder name. As soon as I right-click it (when the context menu opens) the counter gets updated.

I have changed from TLS to no encryption, and the issue remains.

I am running a Dovecot Imap server on my local Debian Etch server.

The previous version (2.2) of Evolution worked properly. I suppose that the new database backend (based on sqlite) introduced this bug, along with a lot of other bugs, really poor performance, and really high memory usage.
Comment 28 Srinivasa Ragavan 2008-11-27 04:59:15 UTC
Guys, so, IIUC the total/unread count on the top of folder treee (info-label) is correct and only the unread count on the folder tree is wrong. I will take this with more prio, and work on it next week.
Comment 29 Fabio Muzzi 2008-11-27 16:30:30 UTC
(In reply to comment #28)
> Guys, so, IIUC the total/unread count on the top of folder treee (info-label)
> is correct and only the unread count on the folder tree is wrong.

Yes, this is correct. I have just re-tested it. The top of the folder tree updates in less than one second after I chage the unread status of a message, while the unread count near to the folder name needs a right-click on it to update.
Comment 30 Alex Murray 2009-04-08 22:34:00 UTC
I have suffered from this bug for a while when using Evolution with GMail IMAP. Sometimes evolution displays that there are unread mails even when there are none. Also, in my case both the info-label and the count on the folder tree are incorrect (and both are the same value). This usually occurs after reading all new emails, they get marked from unread as read and the count at this point is correct saying 0 new emails, but then after closing evolution and opening it back up, it now says 1 or maybe 2 unread emails, even though none are marked as unread, and if I select to show only unread messages for that folder, there are none to display.

One workaround I have found is to mark en existing read message as unread (the unread mail count now increments with this new manually marked unread mail from say the bogus value of 1 to 2) then if I select 'mark message as read' for this one, then the total unread mail count correctly shows as 0 unread.
Comment 31 Akhil Laddha 2009-09-01 05:27:50 UTC
*** Bug 541421 has been marked as a duplicate of this bug. ***
Comment 32 Akhil Laddha 2010-03-30 11:58:04 UTC
Could anyone please confirm if he is still seeing the issue with evolution 2.28.3 or current stable 2.30.0, tia
Comment 33 Jean-François Fortin Tam 2010-09-23 03:43:16 UTC
Akhil: I'm still seeing this folder count mismatch in 2.30.3. Gmail through IMAP+ backend.
Comment 34 psychotic.anomaly 2010-10-31 07:50:23 UTC
(In reply to comment #33)
> Akhil: I'm still seeing this folder count mismatch in 2.30.3. Gmail through
> IMAP+ backend.

I am having the same problem on 2.30.3 with gmail imap folder counts not "syncing" correctly even if there is no mail in the folder or on the server (false report of mail still inside folder with evolution.)
Comment 35 Akhil Laddha 2010-11-12 08:38:38 UTC
*** Bug 588211 has been marked as a duplicate of this bug. ***
Comment 36 Akhil Laddha 2010-11-12 08:38:49 UTC
*** Bug 591127 has been marked as a duplicate of this bug. ***
Comment 37 Milan Crha 2011-09-12 08:12:54 UTC
*** Bug 658669 has been marked as a duplicate of this bug. ***
Comment 38 Stanislav Brabec 2011-11-08 14:20:35 UTC
The problem appears (again?) with evolution-3.2.1, evolution-data-server-3.2.1. I have an IMAP folder with 4 unread mails. One hour ago Evolution was displaying "4 unread mails". Now it displays "6 unread mails" but still shows only 4 unread mails. Using another mail client, I see 4 unread mails as well. In the time between, I manipulated with spam in another folder of the same account.

Note that this bug is different from bug 560382. In that bug, evolution refuses to display some mails. In this bug, mail headers list is correct, and only unread mails counter fails.
Comment 39 Milan Crha 2012-05-31 11:13:45 UTC
There were done changes in (unread) count synchronization for 3.4.0, and I just yesterday fixed also vFolders for 3.5.2 (development version, will be part of 3.6.0). All the above named versions are quite old, unfortunately (basically anything before 3.4.0 is considered old by me). I'm keeping this opened at least till 3.6.0 is out and people will be able to test the changes on their real data.
Comment 40 Stanislav Brabec 2012-06-29 13:16:31 UTC
I just upgraded to evolution-3.4.2 (openSUSE 12.2 beta 2) and see this bug again on an IMAP folder.

I see folder "Drafts (7)" in the folder list, "58 konceptů" ("58 drafts") in the folder list title and "V této složce nejsou žádné zprávy." ("No messages in this folder.") in the messages list.

Looking at the folder directly, there are really no messages.
Comment 41 Milan Crha 2012-07-04 09:44:33 UTC
Created attachment 217992 [details] [review]
eds patch

for evolution-data-server;

This was quite tricky, because I was not able reproduce it on will. It happened to me, from time to time, when I was deleting my spam messages, that the unread count in the folder tree was 1, while real count, in the top info label above the folder tree, was 0 unread messages, same as window's title bar showed
only "Inbox (0 total) - Evolution".

Two issues happened here:
a) when saving summary header to DB, the counts were re-read from the DB,
   instead of writing real values (that's those summary_header_to_db() chunks).
b) there was not used any locking when loading/saving information to/from DB,
   thus this summary_header_to_db() issue could revert back counts of
   the summary, when it was run from a different thread. It was run from
   a different thread for me.
Comment 42 Milan Crha 2012-07-04 09:54:03 UTC
Created commit 42489b2 in eds master (3.5.4+)
Created commit c8f4ed5 in eds gnome-3-4 (3.4.4+)
Comment 43 Milan Crha 2012-07-10 15:10:12 UTC
*** Bug 621217 has been marked as a duplicate of this bug. ***
Comment 44 Matthew Barnes 2012-07-10 15:53:24 UTC
Something is still wrong here.  I've been seeing some crazy unread counts in the folder tree over the past week.

Right now, for example, I'm looking at:  Boston (4294967285)

And the window title says: Boston (-7 unread, 4140 total)
Comment 45 Matthew Barnes 2012-07-10 16:09:52 UTC
Probably should revert the gnome-3-4 commit until this gets sorted out.

The changes are a little too risky for a stable branch anyway, especially in its final update.
Comment 46 Milan Crha 2012-07-11 07:02:29 UTC
(In reply to comment #45)
> Probably should revert the gnome-3-4 commit until this gets sorted out.

Please do not. This change cannot cause it, I only added a little locking and changed that saving to DB will not reread old count values from DB itself. That's the right thing to not read on save.

I guess it's imapx on your side, because here I see correct counts in imap now.
Comment 47 Matthew Barnes 2012-07-14 12:46:20 UTC
(In reply to comment #41)
> Two issues happened here:
> a) when saving summary header to DB, the counts were re-read from the DB,
>    instead of writing real values (that's those summary_header_to_db() chunks).

I reverted this part of the patch and message counts are back to normal now.

http://git.gnome.org/browse/evolution-data-server/commit/?id=963e448dd68b5ffd335c8d11e342cc0f6e30db59

http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-4&id=5819cde4f10283cdd67a2851ebce457238fcaff4

Closing as FIXED until further issues are observed.
Comment 48 Milan Crha 2012-07-16 09:27:05 UTC
I do not think it's correct. Either IMAP or IMAPx does something wrong with summary, because currently the folder summary is kept in sync properly, all the counts are updated internally in it, the users of it cannot change counts in other than CamelMessageInfo::flag changes, and even that should be done through CamelFolderSummary API.

You know that the part you reverted is in summary_header_to_db(), thus this is used to *save* current summary state into DB. It feels naturally incorrect to read from DB when you are saving your current state in it.
Comment 49 Matthew Barnes 2012-07-16 11:56:34 UTC
(In reply to comment #48)
> I do not think it's correct. Either IMAP or IMAPx does something wrong with
> summary, because currently the folder summary is kept in sync properly, all the
> counts are updated internally in it, the users of it cannot change counts in
> other than CamelMessageInfo::flag changes, and even that should be done through
> CamelFolderSummary API.

The message count regressions I was seeing with IMAPX were far more severe then the occasional inaccurate unread count being reported here.  I was seeing negative numbers on even the total message count.

The logic I reverted back to does smell like a hack to me, and your changes may well be correct in the end, and you may even be right that IMAPX is doing something wrong.  But IMAPX is our most important Camel provider, so it needs to be dealt with as part of this bug report and not simply left broken.
Comment 50 Matthew Barnes 2012-07-16 12:01:46 UTC
(In reply to comment #48)
> I do not think it's correct. Either IMAP or IMAPx does something wrong with
> summary, because currently the folder summary is kept in sync properly, all the
> counts are updated internally in it, the users of it cannot change counts in
> other than CamelMessageInfo::flag changes, and even that should be done through
> CamelFolderSummary API.

The message count regressions I was seeing with IMAPX were far more severe then the occasional inaccurate unread count being reported here.  I was seeing negative numbers on even the total message count.

The logic I reverted back to does smell like a hack to me, and your changes may well be correct in the end, and you may even be right that IMAPX is doing something wrong.  But IMAPX is our most important Camel provider, so it needs to be dealt with as part of this bug report and not simply left broken.
Comment 51 Milan Crha 2012-07-16 16:12:58 UTC
*** Bug 659695 has been marked as a duplicate of this bug. ***
Comment 52 Milan Crha 2012-09-04 17:13:18 UTC
*** Bug 683291 has been marked as a duplicate of this bug. ***