crash or restart can cause bad unread totals count in news folder pane

RESOLVED WORKSFORME

Status

MailNews Core
Networking: NNTP
RESOLVED WORKSFORME
16 years ago
9 years ago

People

(Reporter: asa, Assigned: Bienvenu)

Tracking

(Blocks: 1 bug)

Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3])

(Reporter)

Description

16 years ago
If I have read any newsgroup messages during the session and I crash the next
time I start up the unread totals are wrong. I believe that what is happening is
that we're not saving to the summary file regularly and if we crash and have not
saved to summary we get a bad count on next start up or something like that. 

Symptions: the total unread in the server pane is too high for groups that had
newly read message in the crashing session and the threadpane thread icon is
green on threads where all the messages show up as read. If I hit advanced to
next unread message button and all messages are read but the count in folder
pane says there are more unread then nothing happens. 

Steps to reproduce:
1. Set up a news server and subscribe to a group.
2. Read several messages in that group.
3. Make Mozilla crash.
4. Restart Mail-News and observe unread total is too high.
(Assignee)

Comment 1

16 years ago
Stephen, we can't write out the newsrc file every time a message is read - it's
size would make that prohibitive, because it contains the read state for all the
messages in all the newsgroups you're subscribed to. So we write it out on a
timer, every five minutes, and when you shutdown. And since we trust the newsrc
file over anything else, for compatibility and interoperability reasons, we're
pretty much stuck with this situation. So my guess would be that this is "won't
fix". It's just best not to crash.
Status: NEW → ASSIGNED
when asa described this in my cube, it sounds like after crashing, and then
restarting, we'd get the read / unread correct (for each article, as it was on
the time we last wrote the newsrc) but the totals in the folder pane were off.

on loading of a newsgroup, do we reset the totals the nsIDBFolderInfo (and the
folder cache entry), or do we just update them by a delta? 
(Reporter)

Comment 3

16 years ago
If we rely on newsrc as the ultimate authority and it says a message is unread
then that message should be unread when I look at it in the threadpane and
folderpane. What we're doing now is saying that it's unread in threadpane and
folderpane but the message is showing up as read so the two don't jive. I'm OK
with returning after a crash to see that the messages I read during that session
are all unread. I believe this happens in mail to me with some regularity.
That's not a problem at all. I just mark them read and I'm good to go. The
problem with News is that I can't just mark them as read. The messages show up
as read and reading them again fails to change the unread count or update the
spool thread icon that still shows unread in the thread. 

Comment 4

16 years ago
A remark on bienvenu@netscape.com's explanation: The problem also occurs when I
haven't read news for much more than five minutes and Mozilla crashes. Even
after hours. So you always have groups with unread messages which are impossible
to reach. AFAICS mark group read is the only way out.

Keywords: dataloss

pi

Comment 5

16 years ago
To add even more. Say, the problem occured. You go thru all the groups and
everything is at zero. You close Mozilla and restart. Again the same wrong
numbers come up. AFAICS this happens in those groups which go to zero by
entering  (as opposed to Mark Newsgroup Read).

pi
*** Bug 103276 has been marked as a duplicate of this bug. ***
Bug 90991 sounds like it could be a DUP of this, or vice-versa.  Any takers?
(Assignee)

Comment 8

15 years ago
Please let me know if you see this with today's trunk build. I checked in sync
code last night that makes it so sync the newsrc line with the db state if they
disagree (we trust the newsrc line over the db state, so you may lose the fact
that you've marked messages read in the last five minutes before crashing).
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 9

15 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020603

I was just reading news when the news server refused to connect. It looks like
previously read groups were correct, but the very group I was reading when the
problem happened lost information on the last few articles (some minutes) I had
read. Not sure if this confirms your fix or to the opposite. What exactly should
have happened?

pi

Comment 10

15 years ago
Sorry for the additional e-mail.

Now, that I completely read the group in question (getting it to a zero count)
and coming back it has a postive count which won't go down. Mark group read does
work, though. I think, this should have been fixed by this patch, right?

pi
(Assignee)

Comment 11

15 years ago
yes, that's what should have happened. The newsrc is not flushed to disk as
often as the .msf file, and since we trust the newsrc over the .msf file
(because other clients can write to the .newsrc), you will tend to lose the last
few messages you've read.
(Assignee)

Comment 12

15 years ago
but not your last comment - however, are you using a trunk build now?

Comment 13

15 years ago
Yes, same version for comment 9 and comment 10.

pi

Comment 14

15 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610

I just had another crash (Java sucks). I again had to use mark group read.

pi
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

15 years ago
Blocks: 71728

Comment 15

15 years ago
Yep, this still happens for me too, Linux trunk.

Comment 16

15 years ago
I have also seen it with recent nightlies without a crash:-(

pi

Comment 17

15 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021113

Still seeing this. No crash needed. It just happens (often, not always) after
starting Mozilla. Any idea for a better summary?

pi
OS: Windows 2000 → All
Hardware: PC → All

Comment 18

15 years ago
Still seeing it. It really sucks. Changing summary.

pi
Summary: crash causes bad unread totals in news folder pane → crash or restart can cause bad unread totals in news folder pane

Updated

15 years ago
Keywords: nsbeta1

Updated

15 years ago
Keywords: nsbeta1+

Updated

15 years ago
Keywords: nsbeta1

Comment 19

15 years ago
Mail triage team: nsbeta1+/adt3
Whiteboard: [adt3]

Updated

15 years ago
Flags: blocking1.3?
Summary: crash or restart can cause bad unread totals in news folder pane → crash or restart can cause bad unread totals count in news folder pane
(Reporter)

Updated

15 years ago
Flags: blocking1.3? → blocking1.3-

Comment 20

14 years ago
Is this bug meant to include the read/unread state of individual messages, or
only the counts?

Re: comment 1

Nonsense - there are many levels between updating it after every read and not
updating it at all.  Here are some possibilities for when we can decide to
update it:

- when messages are copied to a folder
- when the user leaves the 'group
- when Get Msgs is done
- when a Mark Newsgroup Read operation is done
- when the user clicks to remove expired messages, before actually doing the remove
- at regular intervals
and so on.

See also bug 192903 comment 2.

Updated

14 years ago
Blocks: 237647
(Reporter)

Comment 21

13 years ago
unable to reproduce with Mozilla 1.7 beta and newer builds (looking for this
problem in both seamonkey and firebird over the last few weeks)
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago13 years ago
Resolution: --- → WORKSFORME

Comment 22

13 years ago
Still happens to me occasionally. You have to force the message read to get the
count correct again. There is no way to reproduce, it just happens.

pi
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Product: MailNews → Core
(Reporter)

Comment 23

11 years ago
I'm no longer seeing this in the latest Thunderbird builds. 
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago11 years ago
Resolution: --- → WORKSFORME
No longer blocks: 71728
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.