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).

"using %d but parameter is gsize' file as bugs, with patches if you can ;-).

ok, added bug #544031

$HOME/.evolution/mail/local is not created #544048

crash with my imap folder: bug #544049

SIGSEGV in camel_sexp_to_sql, bug #544528. Repeatable.

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.

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

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.

I just filed bug 546215 which could be related to this, too... at least it started happening after 2.23.4

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.

Add bug 547852 to this list?

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.

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.

(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.

(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.

(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.

Created attachment 116858 [details]
Screenshot for my last comment

(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.

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

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

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
 

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.

David, Im fixing vfolder counts. Are counts broken in normal folders?

yes (see, e.g., comment #23)

David

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.

David, you use exchange provider if i am right and count issue is not yet resolved for exchange.

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.

I just did a svn upgrade/reinstall.   The count problem now seems to only happen in search folders.  The others behave as expected :)!!!

Search folders are also done. Now, there might some one off scenarios, that I myself cant catch. Please test and lemme know.

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

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'"

(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.

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.

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?

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)

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.

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!

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.

API breakage -> Blocker for 2.24.

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.

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.)

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.

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

(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.

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.

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.

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.

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.

Fixed the counts on trunk. Guys update again and lemme know how it goes.

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... 

Michael, Have a watch, if you are able to see a pattern lemme know. Meanwhile, I will try myself to reproduce it.

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.

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"

> 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

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.

Larry, this particular issue would be fixed with the patch at bug #557348. I had posted the patch just today.

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.

BTW: comment #58 was most definitely intended with a :-)

@gnome-bugs: Comments don't say much - this is a METAbug. See

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?

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.

This task has served its purpose. Hence closing.