Closed Bug 23542 Opened 25 years ago Closed 24 years ago

Unread message count incorrect at startup

Categories

(MailNews Core :: Backend, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: rzach, Assigned: Bienvenu)

Details

This is not what's described in bug 18825, but might be related:

The unread message count in the account pane which is displayed on startup often
does not match the unread message count when MailNews was last closed.  The
effect is most noticeable on IMAP folders: The message count will be displayed
as x first, then when you select the folder it changes to some number y, and
when the folder is finished loading, the count changes to the new actual number
of unread messages z.

Now x and y should always be the same and should be equal to the number of
unread messages the last time the folder was open.

It looks to me like the unread message counts that the account pane display uses
on startup and the count it uses when a folder is selected are different and not
stored in the same circumstances.  I've tried various scenarios but wasn't able
to come up with an exactly reproducible testcase.  I think Get Msg saves the
number displayed as x but not as y, but closing the mail window or marking a
message read or unread don't.  I have no idea where y comes from.

Similar things happen on local and POP folders, although in this case there's
only x and z to worry about.

Linux build 2000.01.10.08
Assignee: phil → putterman
Summary: Unread message count incorrect at startup → Unread message count incorrect at startup
Yes, there have been some fixes in this area lately. Could you try to delete
your .msf files and see if the problem persists? Reassigning to putterman.
this still happens.  There's been no fix for it.
I deleted my .msf files; now my message counts are completely off (account pane
says 0 unreads, buth there are half a dozen).
I think I see this bug every so often as well.  cc'ing bienvenu.  In theory x
and y should be the same if we write out the folder cache.
Status: NEW → ASSIGNED
Target Milestone: M16
something to be aware of - if the app crashes before or during shutdown, the 
folder cache will not get written out, so the counts will be off, and closing 
mail/news is not sufficient - you have to close the browser as well. I have a 
bug on this - 18346
I see no way to get the unread count back in sync with reality after a crash.
The thread leader might show 2 unread, the folder indicates 2 unread, but in
fact there are no unread in the thread. So how to reset? Might I suggest that
using Mark|All Read go though and fix the thread leader as well as setting no
unread on the folder. That way you can at least get things back in sync.

This will be very confusing for users as it is right now. Since it looks like
bug 18346 is not going to be fixed for beta1, maybe this could be implemeted?

You can delete your .msf file for the folder that's messed up. The decision not 
to fix bug 18346 means that we are basically going to live with this bug for 
beta1 (i.e., I couldn't get approval to fix this from the Powers That Be)
reassigning to bienvenu.
Assignee: putterman → bienvenu
Status: ASSIGNED → NEW
accepting
Status: NEW → ASSIGNED
Not M16 stopper.  Marking M17.
Target Milestone: M16 → M17
marking M18 and nominating for beta3.
Keywords: nsbeta3
Target Milestone: M17 → M18
Keywords: correctness
Richard, do you use mail filters? That could cause the counts in folders that
have messages filtered into them to be wrong at startup, because we weren't
accounting for the "pending" headers in the folder cache counts. So if you get
messages filtered into a folder, shut down without opening that folder, and then
restarted, the count would be wrong. 
No, I'm not using filters.  I haven't tested this in a while...
can't reproduce this. Perhaps commiting the summary file more often will help.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Linux (2000-07-28-04 M17)
Win32 (2000-07-28-12 M17)
mac (2000-07-26-08 M17)
This problem no longer exists.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.