Closed Bug 101503 Opened 23 years ago Closed 18 years ago

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

Categories

(MailNews Core :: Networking: NNTP, defect)

Product:
MailNews Core
Component:
Networking: NNTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: asa, Assigned: Bienvenu)

References

Details

(Whiteboard: [adt3]) 

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.
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? 
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. 
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
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?
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
Closed: 22 years ago
Resolution: --- → FIXED
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
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
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.
but not your last comment - however, are you using a trunk build now?
Yes, same version for comment 9 and comment 10.

pi
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 → ---
Blocks: messagecount
Yep, this still happens for me too, Linux trunk.
I have also seen it with recent nightlies without a crash:-(

pi
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
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
Keywords: nsbeta1
Keywords: nsbeta1+
Keywords: nsbeta1
Mail triage team: nsbeta1+/adt3
Whiteboard: [adt3]
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
Flags: blocking1.3? → blocking1.3-
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.
Blocks: failsafe
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
Closed: 22 years ago → 21 years ago
Resolution: --- → WORKSFORME
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
I'm no longer seeing this in the latest Thunderbird builds.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 18 years ago
Resolution: --- → WORKSFORME
No longer blocks: messagecount
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.