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 543389 - Camel Disk summary bugs
Camel Disk summary bugs
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.24.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[disk-summary]
: 548502 548513 (view as bug list)
Depends on: 213072 313712 355007 387050 438772 444418 543376 543388 543401 543407 543409 543411 543413 543427 543569 543943 544031 544049 544114 544115 544202 544491 544497 544501 544506 544651 544666 544825 545081 545082 545099 545103 545317 545436 545505 546184 546194 546215 546385 546388 546397 546415 546452 546464 546508 546544 546635 546637 546972 547256 547389 547469 547763 547798 547802 547852 548059 548148 548297 548331 548343 548381 548450 548671 548826 548865 549311 549420 549913 550414 550466 552403 552552 552705 552731 552771 553298 553405 553862 554282 554332 554455 554530 554531 554861 554990 555080 555276 555660 555731 555979 556122 557348 557510 557618 558472 558883 558926 559056 559153 560076 560325 561021 561069 561170 561549 561584 561639 561644 561983 562220 562350 562449 562667 562868 562912 562979 562988 563118 563123 563326 563352 563355 563947 563954 564213 564388 564954 565363 566518 566653 566887 567261 568193 568194 568297 568332 568421 569405 569576 569742 569883 569986 570279 570329 571206 571995 573125 573170 573177 574534 575701 576390 576398 576430 576488 576953 577387 577542 578535 578910 580408 581314 581720 584352 584624 586483 588448 595389 608457 621878
Blocks:
 
 
Reported: 2008-07-17 08:14 UTC by Akhil Laddha
Modified: 2017-09-24 15:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Screenshot for my last comment (224.50 KB, image/png)
2008-08-18 12:02 UTC, Reid Thompson
Details
Another count bug (21.31 KB, image/png)
2008-09-12 22:20 UTC, Michael Monreal
Details
Count bug in 2.24.2 (180.99 KB, image/jpeg)
2008-12-02 13:44 UTC, SchAmane
Details

Description Akhil Laddha 2008-07-17 08:14:29 UTC
This is a tracker bug for the bugs which will appear after disk summary changes merged in trunk.
Comment 1 Milan Crha 2008-07-17 10:04:18 UTC
Should I file a bug for getting rid of all of those thousands compiler warnings here and there? I've 64bit and it also claims on parameter sizes, like "using %d but parameter is gsize" or similar (the warning gone because of libical warnings).
Comment 2 Srinivasa Ragavan 2008-07-19 20:13:30 UTC
"using %d but parameter is gsize' file as bugs, with patches if you can ;-).
Comment 3 Milan Crha 2008-07-21 16:55:10 UTC
ok, added bug #544031
Comment 4 MatzeB 2008-07-21 19:24:15 UTC
$HOME/.evolution/mail/local is not created #544048
Comment 5 MatzeB 2008-07-21 19:30:12 UTC
crash with my imap folder: bug #544049
Comment 6 C de-Avillez 2008-07-24 11:38:40 UTC
SIGSEGV in camel_sexp_to_sql, bug #544528. Repeatable.
Comment 7 Matthew Barnes 2008-08-01 15:09:15 UTC
Can we make it a point to remove all the #warning directives before 2.24?

The convention is to mark "fix me later" type issues in the code with comments having easily greppable prefixes such as XXX, FIXME or TODO.

Seeing that garbage in compilation output is really distracting when I'm trying to check for actual compiler warnings.
Comment 8 Srinivasa Ragavan 2008-08-03 06:25:02 UTC
Matt, the point to have #warnings is to fix it asap, (before 2.24). I really dont want to loose them in the sea of FIXMEs already. So I will fix all or move thelater to FIXME's
Comment 9 Matthew Barnes 2008-08-03 14:15:32 UTC
You could use a disk-summary-specific comment prefix that's easily greppable to avoid losing them in the sea of FIXMEs.  FIXME[DISK-SUMMARY] or some such.
Comment 10 Michael Monreal 2008-08-04 10:37:07 UTC
I just filed bug 546215 which could be related to this, too... at least it started happening after 2.23.4
Comment 11 Michael Monreal 2008-08-05 18:24:21 UTC
Another one... bug 546453. I'm not 100% sure if my mail db has been corrupted before the disk summary stuff but I don't think so. Please see if you think this is related.
Comment 12 Michael Monreal 2008-08-14 23:23:45 UTC
Add bug 547852 to this list?
Comment 13 Reid Thompson 2008-08-15 11:27:00 UTC
built from svn head
evolution --force-shutdown
rm  -rf  .evolution/exchange/ .evolution/mail/exchange/
restart
evo began rebuilding summaries, etc, etc
evo finished rebuilding summaries etc etc

Comments in two sections below LOCAL INBOX and EXCHANGE OWA.

LOCAL INBOX:
I have pop account going to 'local' folders.
Filters either leave the mail in Inbox, or move the email to the appropriate
local folder.
start looking through folders, checking for issues...
Several folder appear fine...
Issue 1)  folder has 8 msgs, 1 unread BUT list pane shows every email twice
except for the Unread one and the info label shows 2 unread, 16 total.  Leaving
the unread email selected until it becomes 'read' causes Unread count to drop
to
1 (still incorrect though).  CTRL-A notes 15 selected, 16 total
Issue 2) folder has same problem as Issue 1, info label lists 16 unread 1358 
total.  CTRL-A notes 1357 selected, 1358 total.  If I tell list pane to show
only unread messages and CTRL-A, info pane notes 16 unread and 14 selected
Issue 3) folder same as 1 and 2, info label lists 288 drafts, tree notes 188
unread.  All drafts are listed twice.  CTRL-A notes 188 selected, 282 drafts.
List pane shows NO messages as unread.


EXCHANGE OWA:
Issue1) Inbox tree view lists 315 unread info label lists -3 unread -24 total

File/Quit
evolution --force-shutdown
restart

let evo refresh and fetch summaries....

LOCAL INBOX:
folder with Issue 1 above is now correct -- tree lists no unread messages, info
label lists 8 total. 
folder with Issue 2 above appears correct -- tree lists 6 unread info label
lists
6 unread 679 total.  CTRL-A notes 679 selected 679 total
folder with Issue 3 above tree notes 94 unread Info label lists 94 drafts.
CTRL-A info label notes 94 selected 94 drafts

EXCHANGE OWA:
Inbox tree view lists 318 unread info label lists 315 unread 1539 total

I select my spam folder - it has 6 msgs, all unread, tree view lists 6 unread
info label lists 6 unread 6 total.  I begin deleting msg by msg. after deleting
3 msgs and letting cursor selection turn two of the remaining 3 to 'read', tree
notes 1 unread, info label notes 1 unread 6 total ( ??? 3 visible + 3 deleted
but hidden msgs  ??? ). File empty trash -> info label still lists 6 total.
CTRL-E expunge, info label still lists 6 total.  select another folder and
return, still lists 6 total.

Other folders have mis-matches between tree unread and info label unread

Folder/Refresh Folder does not correct invalid information.
Comment 14 Srinivasa Ragavan 2008-08-18 09:44:32 UTC
Reid,

Wrt Local folders, was it on first start or after any fetching it goes like this?

I know for local, a refresh/switch of hte folder fixes it, but trying to fix it first time.
Comment 15 Reid Thompson 2008-08-18 11:46:56 UTC
(In reply to comment #14)
> Reid,
> 
> Wrt Local folders, was it on first start or after any fetching it goes like
> this?
> 
> I know for local, a refresh/switch of hte folder fixes it, but trying to fix it
> first time.
> 

It was on first start - A restart cleared it up.  HOWEVER, I left evo running over the weekend, and this morning, one of the local folders was listing all emails twice again.  A restart cleared it up again.  So it looks like it may occur at anytime.
Comment 16 Reid Thompson 2008-08-18 11:55:56 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Reid,
> > 
> > Wrt Local folders, was it on first start or after any fetching it goes like
> > this?
> > 
> > I know for local, a refresh/switch of hte folder fixes it, but trying to fix it
> > first time.
> > 
> 
> It was on first start - A restart cleared it up.  HOWEVER, I left evo running
> over the weekend, and this morning, one of the local folders was listing all
> emails twice again.  A restart cleared it up again.  So it looks like it may
> occur at anytime.
> 

It can happen anytime.  I just restarted evo and one of the local folders came up with all listed twice in the view.
Comment 17 Reid Thompson 2008-08-18 12:01:28 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > Reid,
> > > 
> > > Wrt Local folders, was it on first start or after any fetching it goes like
> > > this?
> > > 
> > > I know for local, a refresh/switch of hte folder fixes it, but trying to fix it
> > > first time.
> > > 
> > 
> > It was on first start - A restart cleared it up.  HOWEVER, I left evo running
> > over the weekend, and this morning, one of the local folders was listing all
> > emails twice again.  A restart cleared it up again.  So it looks like it may
> > occur at anytime.
> > 
> 
> It can happen anytime.  I just restarted evo and one of the local folders came
> up with all listed twice in the view.
> 
This can also have the effect of ??corrupting the index?? of the emails in the folder -->  Selecting an email in the view displays a completely different email.  See attachment.
Comment 18 Reid Thompson 2008-08-18 12:02:31 UTC
Created attachment 116858 [details]
Screenshot for my last comment
Comment 19 Reid Thompson 2008-08-18 12:05:04 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > Reid,
> > > > 
> > > > Wrt Local folders, was it on first start or after any fetching it goes like
> > > > this?
> > > > 
> > > > I know for local, a refresh/switch of hte folder fixes it, but trying to fix it
> > > > first time.
> > > > 
> > > 
> > > It was on first start - A restart cleared it up.  HOWEVER, I left evo running
> > > over the weekend, and this morning, one of the local folders was listing all
> > > emails twice again.  A restart cleared it up again.  So it looks like it may
> > > occur at anytime.
> > > 
> > 
> > It can happen anytime.  I just restarted evo and one of the local folders came
> > up with all listed twice in the view.
> > 
> This can also have the effect of ??corrupting the index?? of the emails in the
> folder -->  Selecting an email in the view displays a completely different
> email.  See attachment.
> 

again, a shutdown and restart clears it.
Comment 20 André Klapper 2008-08-19 20:53:23 UTC
*** Bug 548513 has been marked as a duplicate of this bug. ***
Comment 21 André Klapper 2008-08-19 20:53:26 UTC
*** Bug 548502 has been marked as a duplicate of this bug. ***
Comment 22 David Ronis 2008-09-04 16:43:45 UTC
I've just updated to today's SVN evo and friends.  The summary counts are still broken.  Here's what I see:

1.  Initial start-up counts are fine
2.  Deleting mail works, but summary counts don't decrease.
3.  Deleting mail one at a time in search folders works (summary counts decrease), deleating all of them at once (by selecting all messages before pressing delete) doesn't
 
Comment 23 David Ronis 2008-09-04 16:57:10 UTC
One more observation:

I restarted evo and marked 3 messages as junk.  They were removed from the folder (and the count was correctly reduced by 3).  When I went to the junk folder there were 15 messages there; the count showed 3.  Selecting all the messages (crtl-A) and then pressing delete removed all the junk mails, but the count now shows -12.
Comment 24 Srinivasa Ragavan 2008-09-04 17:59:29 UTC
David, Im fixing vfolder counts. Are counts broken in normal folders?
Comment 25 David Ronis 2008-09-04 18:09:23 UTC
yes (see, e.g., comment #23)

David
Comment 26 David Ronis 2008-09-04 22:37:45 UTC
More on comment #25.  Just started evo again.  Initial counts weren't right on folder populated by a filter.  Said that there were 3 messages, 2 unread.  Message pane showed 2 messages, one unread.  After selecting all messages (ctrl-A) and deleting, summary showed 1 unread, but no messages were in list, which had message "No messages in this folder".  

On the other hand, I had 2 new messages in my Inbox (correct this time) and I was  able to delete them one at a time.


Comment 27 Akhil Laddha 2008-09-05 04:31:13 UTC
David, you use exchange provider if i am right and count issue is not yet resolved for exchange.
Comment 28 David Ronis 2008-09-05 14:58:08 UTC
While I would like to use exchange, I'm not.  It's broken since my site has upgraded to Exchange2007.  I've tried the MAPI interface, but I gather that this is not working for the latest evo's.  In any event, the accounts I'm using are either local mbox's or pop3.

Comment 29 David Ronis 2008-09-05 16:37:13 UTC
I just did a svn upgrade/reinstall.   The count problem now seems to only happen in search folders.  The others behave as expected :)!!!
Comment 30 Srinivasa Ragavan 2008-09-11 05:34:19 UTC
Search folders are also done. Now, there might some one off scenarios, that I myself cant catch. Please test and lemme know.
Comment 31 Michael Monreal 2008-09-11 10:22:46 UTC
Srinivasa: about search folders, I just tested this using a "local unread" vfolder with trunk (ran evolution --force-shutdown and deleted folder.db to make sure I started clean):

* marked one mail from inbox unread
=> no change in vfolder count, mail did not show up in vfolder

* marked the mail as read again

* marked 2 other mails from inbox as unread
=> vfolder shows 3 unread
=> opening the vfolder, the 3 mails are displayed (nice!)

* clicking the unread icon of the second mail inside the vfolder to make it read
=> ALL three mails are marked read and disappear from the vfolder
=> vfolder now says (1) in the tree and (-1 unread, 0 total) in the header
Comment 32 Milan Crha 2008-09-11 14:43:42 UTC
I can confirm the above comment of vfolder counts.

I can also add one quite strange behavior, not sure how much related to db-summary. I faced the issue when evo got in an infinite loop when I deleted my vfolder and I was forced to kill evo (when looking on other bug srag gave me).

Next start the folder was there, but I couldn't delete it, furthermore, it was deleted in ~/.evolution/mail/vfolders.xml, but I saw that. I tried to reproduce with these steps:
a) have some vfolders, stay on one and close evo;
b) check next start the folder will be selected, close evo
c) delete the selected folder (rule) from vfolders.xml file and start evo

I can see for a tick of a second the folder there, but then that gone, but the "Loading..." note is left there. I believe it depends on the position in tree what will happen, because this I did with the near-last folder, but if I do this with first folder under the Search Folders, then the folder seems to be there as before, only attempt to use it does nothing, deleting deletes it, but claims on the console "Cannot find rule for deleted vfolder 'aaa'"
Comment 33 Srinivasa Ragavan 2008-09-11 14:53:30 UTC
(In reply to comment #31)
> Srinivasa: about search folders, I just tested this using a "local unread"
> vfolder with trunk (ran evolution --force-shutdown and deleted folder.db to
> make sure I started clean):
> 

Michael, I assume that you are using a version.. camel/ChangeLog has
2008-09-11  Srinivasa Ragavan  <sragavan@novell.com>
    
    	* camel/camel-vee-folder.c: Make counts work even better.
    	* camel/camel-vee-summary.c:
    	* camel/camel-vee-summary.h: Do force counts better.


Can you confirm back? I commited it 10-13 mins before you commented on the bug.. so just checking for sure.
Comment 34 Srinivasa Ragavan 2008-09-11 15:48:24 UTC
Michael,

Im not able to reproduce it :(..

Did you delete ~/.evolution/vfolder/folders.db ? Thatz the one, that takes care of vfolders.

I have up to date eds/evo. I have 2 vfolder one for all local unread mails and other for local label:important.

I start up, when INBOX is selected. Mark a mail as unread, I see the folder tree count increasing :( and the reverse too happens.
Comment 35 Srinivasa Ragavan 2008-09-11 15:50:48 UTC
Michael,

Im not able to reproduce it :(..

Did you delete ~/.evolution/vfolder/folders.db ? Thatz the one, that takes care of vfolders.

I have up to date eds/evo. I have 2 vfolder one for all local unread mails and other for local label:important.

I start up, when INBOX is selected. Mark a mail as unread, I see the folder tree count increasing :( and the reverse too happens correctly.

Any more steps to reproduce?
Comment 36 Michael Monreal 2008-09-11 16:51:05 UTC
Srinivasa, no I did not yet have this revision but I updated to trunk now. The count really seems to work fine now, but I still get this "mark one mail read inside the search folder and all get marked read" thing.

(btw yes I deleted ~/.evolution/vfolder/folders.db)
Comment 37 Srinivasa Ragavan 2008-09-11 18:28:05 UTC
Michael, do you try to open a (unread) mail in vfolder of unread mails and all others are going off?  if so, then bug #546637
With that assumption:
It is a totaly different issue, that we have to solve. Milan solved a similar issue for normal folder, unread messages view, which had the similar thing.
Comment 38 Michael Monreal 2008-09-11 20:34:19 UTC
Hmm I thought it was marking unread that triggered it but opening is just the same, so it's the same as bug #546637. Thanks!
Comment 39 Matthew Barnes 2008-09-11 21:44:36 UTC
I'm getting some reports of API compatibility problems from third-party extensions that build against libcamel.

First issue, in camel-db.h:

  struct _CamelDB {
          sqlite3 *db;
          GMutex *lock;
          const char *sort_by;
          const char *collate;
          CamelDBCollate collate_cb;
  #if CAMEL_DB_DEBUG      
          GTimer *timer;
  #endif
  };

It should be #ifdef, not #if, since nothing in the public API defines CAMEL_DB_DEBUG.  Furthermore, I'm not sure it's such a good idea to be putting conditional struct members in a public header.  As soon as you flip the CAMEL_DB_DEBUG status you've now broken ABI and have to recompile any packages that are linked to libcamel.

I'd suggest defining a CamelDBPrivate struct in camel-db.c and moving the GTimer there.  Then replace the GTimer pointer with a CamelDBPrivate pointer in the public header.


Second issue, in camel-folder-summary.h:

  #if 0  /* Deprecated */
        GPtrArray *messages;    /* CamelMessageInfo's */
        GHashTable *messages_uid; /* CamelMessageInfo's by uid */
  #endif

This is an API break.  The point of marking something as deprecated is to indicate it will be removed IN THE FUTURE.  Here we've already removed it.
If this is going to stay as is then we need to bump libcamel's soname,
which I don't think we've done yet for disk-summary.
Comment 40 André Klapper 2008-09-11 22:09:01 UTC
API breakage -> Blocker for 2.24.
Comment 41 Srinivasa Ragavan 2008-09-12 04:14:07 UTC
Matthew, your first issue on camel-db.h is valid. It should be IFDEF. Right Matt, it should be private ideally. But that was added just for Kmaraas to get some debugging on timings which I committed later. I should rewrite that portion. But for now, lets modify to #ifdef for now. I don't expect anyone to run with this, and would go off once I see most of the bottle necks gone.


On the second portion.

It is removed. It is a ABI break, not API.Even otherwise, it was a internal member. 
http://svn.gnome.org/viewvc/evolution-data-server/trunk/configure.in?r1=9151&r2=9169

We did update camel so version.

Andre, EDS is not in the platform, though it should be in sometime. Even then, we support libebook/libecal as supported APIs. Camel is never in the picture, and not going to be atleast till 2.26.
Comment 42 André Klapper 2008-09-12 05:00:37 UTC
Srini:
Yupp, API freeze is not required for non-platform libraries, but is recommended. So I expect it, especially that late in the cycle.
Hence for me it's a blocker until it's not completely fixed. :)
(Writing this being a bit drunk at 7AM, so feel free to ignore the last sentence if it doesn't make sense.)
Comment 43 Srinivasa Ragavan 2008-09-12 05:38:24 UTC
andre :-)

So, the change was done during 2.23.5 (camel-folder-summary.h) and version bumped accordingly that time. Nothing recent. The camel-db.h change is what is pending and that doesn't have to anything with abi. Camel db is all private. Anyways, committed all to trunk :)

Resetting the blocker status and keeping it critical.
Comment 44 Srinivasa Ragavan 2008-09-12 05:43:01 UTC
Oh wait,

sragavan@novell.com  	2008-09-12 04:14:07 UTC  	Severity  	blocker  	critical
GNOME milestone 	2.24.x 	Unspecified 

This was unintentional. I just now, did it intentionally after the fixes to trunk
Comment 45 Matthew Barnes 2008-09-12 13:25:04 UTC
(In reply to comment #41)
I'm fine with your proposal for the first part (#if -> #ifdef).

Once I get around to "GObjectizing" Camel, I think I'd like to seal (as in G_SEAL) all the public struct members in Camel, like what GTK+ is doing for 3.0.  So the conditional debugging stuff will be privitized eventually anyway.

For the second part I think it's both an ABI and API break.  For better or worse, Evolution-Brutus seems to be accessing those members directly and fails to compile now.  We might want to lend a hand to Jules to get his code working again in time for 2.24.

Sorry about not noticing the Camel soname bump.  The changes you made aren't recent but I think its effects are only just now being felt.
Comment 46 Srinivasa Ragavan 2008-09-12 15:42:26 UTC
Matt, we should freeze camel apis. But lets take a release for that.

I had Mailed personally to Jules may be around 2.23.2 time or so about the porting need for the disk summary branch.
Comment 47 Michael Monreal 2008-09-12 22:20:43 UTC
Created attachment 118629 [details]
Another count bug

After counts were working nicely for a day now, I just got another "corruption" of the unread count. No real way to reproduce (I had ~15 new mail and after reading them all, the unread cound was stuck like this). The count is still wrong after restarting evo.
Comment 48 Srinivasa Ragavan 2008-09-13 03:58:48 UTC
Cool. Possibly, there are some corner cases like this. To reset it, start with FORCE_VFOLDER_COUNT env set, and close evo. That should fix it, by rebuilding counts. But thatz just work around. But I need to see how it went bad. What is the sitn? Can you try to find the pattern?

Thanks Michael.
Comment 49 David Ronis 2008-09-14 01:06:05 UTC
RE: comment #47, I can confirm.  In my case I'd just gone to the junk folder, selected all the messages and pushed delete.  They were all deleted properly, but the count read (and reads) -197.

Purging all index, meta, and .db files didn't work--junk now shows a count of 10, but there are only 5 messages showing.

Restarting with FORCE_VFOLDER_COUNT=y still shows the wrong count of 10,  although after closing and restarting it is now correct.

Comment 50 Srinivasa Ragavan 2008-09-15 11:49:26 UTC
Fixed the counts on trunk. Guys update again and lemme know how it goes.
Comment 51 Michael Monreal 2008-09-19 11:27:23 UTC
Evo has behaved nicely during the last 2 days (no wrong folder count that I noticed). But now the unread vfolder says there's one unread mail again and it's empty. 

The cases where this happens seem to be very rare now but the problem still happens from time to time it seems... 
Comment 52 Srinivasa Ragavan 2008-09-19 16:15:04 UTC
Michael, Have a watch, if you are able to see a pattern lemme know. Meanwhile, I will try myself to reproduce it.
Comment 53 SchAmane 2008-12-01 19:33:49 UTC
I am waiting for hunting down of this bug quiet a long time. And after few releases it still shows wrong number of unread messages near folder, even if count in Unread Overview is properly shown. Is it realy so difficult to fix this?

I would like to help, but i dont know where to start. I can also try to help over IRC.

Since 2.24 released i have to use my web-mail and itouch to read mails. I would like get my loved evolution back to daily usage, but memmory leaks and this "count" bug do this impossible this days.
Comment 54 SchAmane 2008-12-02 13:44:50 UTC
Created attachment 123793 [details]
Count bug in 2.24.2

See picture for comments. Used versions:

[ebuild   R   ] dev-libs/glib-2.19.0  USE="xattr -debug -doc -fam -hardened (-selinux)"
[ebuild   R   ] x11-libs/gtk+-2.14.5  USE="X cups jpeg tiff -debug -doc -jpeg2k -vim-syntax -xinerama"
[ebuild   R   ] gnome-extra/evolution-data-server-2.24.2  USE="gnome-keyring ssl -debug -doc -ipv6 -kerberos -krb4 -ldap"
[ebuild   R   ] mail-client/evolution-2.24.2  USE="crypt dbus hal mono spell ssl -debug -ipv6 -kerberos -krb4 -ldap -networkmanager -nntp -pda -profile"
Comment 55 Bill Case 2009-01-20 18:59:55 UTC
> Is there anyway to make Evolution recount each folder and start again
> with real numbers?

"Known bug. Restart Evolution after setting FORCE_VFOLDER_COUNT=1 in the
environment. See http://bugzilla.gnome.org/show_bug.cgi?id=543389"

Followed the advice given above on Jan 3, 09.  It worked for a while.  Now for the last few days I am getting a persistent miscount in my vFolders.  No amount of fiddling seems to correct it.

Regards Bill
Fedora 10, Gnome 2.24.2
Evo.2.24.2, Emacs 22.2.1
Comment 56 Larry Reaves 2009-01-29 16:11:22 UTC
One thing I have noticed is that if you move a message that is matched in a vfolder from one folder to another that is also searched by that vfolder, the unread count goes up for that vfolder, even though the messages have already been read.  Marking them as unread, then read again resolves this.  It seems to me Bug 558926 isn't quite resolved yet.
Comment 57 Srinivasa Ragavan 2009-01-29 16:23:52 UTC
Larry, this particular issue would be fixed with the patch at bug #557348. I had posted the patch just today.
Comment 58 Brian J. Murrell 2009-04-06 19:33:32 UTC
Does the lack of comments since the end of January reflect the amount of work being done to correct these issues or has everyone just been so busy fixing the issues to make comments?

A new bug has been marked to block this one (admittedly just today), bug 576953.
Comment 59 Brian J. Murrell 2009-04-06 19:50:17 UTC
BTW: comment #58 was most definitely intended with a :-)
Comment 60 André Klapper 2009-04-06 20:18:03 UTC
@gnome-bugs: Comments don't say much - this is a METAbug. See
Comment 61 Brian J. Murrell 2009-08-25 12:11:59 UTC
I notice the GNOME target: 2.26.x has come and gone and there are still open bugs blocking this one.

One in particular that's quite heinous is 569576.  What makes it so heinous is that you end up effectively not getting e-mail that was sent to you unless you troll through all of the real folders that vfolders are meant to be representing, which makes vfolders quite pointless.

Any thots?
Comment 62 Jean-François Fortin Tam 2010-04-05 15:39:54 UTC
Hey there, I stumbled upon a couple of bugs today that seem to be related to this (namely #559391, #588448, #438772, #577542, #553405, #387050, #571995, #313712). I am assuming that all bugs pertaining to incorrect unread mail counts = "disk-summary" bugs, usually. Therefore, I'm adding them so that they don't get lost. Hoping it somehow helps.
Comment 63 André Klapper 2017-09-24 15:17:10 UTC
This task has served its purpose. Hence closing.