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.
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 firstname.lastname@example.org'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).
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?
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
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
Still seeing it. It really sucks. Changing summary. pi
Mail triage team: nsbeta1+/adt3
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.
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)
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
I'm no longer seeing this in the latest Thunderbird builds.