User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050518 Firefox/1.0.4 Build Identifier: Mozilla Thunderbird version 1.0.4 (20050518) There has been much spamming recently on the netscape.public.mozilla.* family of newsgroups, and the admins (or a news robot) have diligently cancelled the offending posts. Reproducible: Sometimes Steps to Reproduce: "Reproducing the problem" depends on circumstances from the other side of the NNTP server, to which I don't have access. Actual Results: After hitting F5 on the news server, a number of groups are bolded with numbers in parentheses (supposedly unread messages) next to their names. Selecting a group, then N etc. may bring up such a group where all unread messages are "phantom" messages already cancelled. In that case the newsgroup name becomes unbold as soon as "N" doesn't find any actual message to read, but at next refresh the same "phantom" messages will again make the group unread with the same number of "unread" messages. If a message was cancelled after reading its heading, the user has the option to "remove all expired messages" but if even the heading wasn't downloaded there is no way to make the problem disappear, except sometimes (apparently not always) by hand-editing the file News\<servername>.rc in the Thunderbird profile after closing Thunderbird. Expected Results: Cancelled messages should not be marked unread, or at most once but not repeatedly. I've been told that this bug also happens on Mozilla News and on Netscape 7 News. Please check that if you can.

Oops. I was interrupted and forgot part of the description. Thanks to the diligent admins but see further down (Actual results) to see the actual description of the bug.

Observe described behaviour with Mozilla Suite from early 1.x till current 1.7.8. Lost hope this to be fixed...

The following workaround is a clumsy one; I hope it will someday be made unnecessary: 1. Refresh all newsgroups in the concerned news server, and read (or mark as read) all messages in all of them. 2. Close Thunderbird. 3. Use any pure-text editor (e.g. Notepad, vim, kedit) to open the <servername>.rc file in the News/ subdirectory of your profile, where <servername> is the name of the concerned news server, for instance news.mozilla.org 4. In every line with several comma-separated numbers or groups or numbers, replace everything by a range "from one to the last mentioned number": e.g. in a line like netscape.public.mozilla.browser: 1-21760, 21763, 21765 replace all the numbers by just 1-21765 -- in this particular example, this effectively "marks as read" three phantom messages in that newsgroup (remember, at step 1 you read everything; there is no "real" unread message). 5. Save the editfile, close the editor, and reload Thunderbird. The "phantom" messages should be gone -- until next time.

Probably this is wrong place for thanks, nevertheless thanks for providing instructions. Yes, I've used this workarround and it worked this time for me. Actually, I discovered myself that there are gaps in read articles numbers and tried to edit. However, I remember that some time ago this led to broken offline archive index. Do not remember details, maybe I did something wrong, so just vote for more attention to this bug.

(In reply to comment #4) > Probably this is wrong place for thanks, nevertheless thanks for providing > instructions. > > Yes, I've used this workarround and it worked this time for me. Actually, I > discovered myself that there are gaps in read articles numbers and tried to > edit. However, I remember that some time ago this led to broken offline archive > index. Do not remember details, maybe I did something wrong, so just vote for > more attention to this bug. One of the reasons of steps 1 and 2 in comment #3 is to avoid bad consequences as far as possible. The workaround has worked for me too, but since I don't know the details of Thunderbird logic, I cannot guarantee that it will always work. (I think it will, but if it doesn't, don't take it on me. ;-) )

I guess this is related to bug 290826. I'm markign it as a duplicate, please reopen if that was a mistake. *** This bug has been marked as a duplicate of 290826 ***

(In reply to comment #6) > I guess this is related to bug 290826. I'm markign it as a duplicate, please > reopen if that was a mistake. > > *** This bug has been marked as a duplicate of 290826 *** > After taking a look at bug 290826, I too believe they are "related" but I don't know the degree of parency. I'm letting the dupe stand for now; please reopen if these two bugs are shown not to be identical.

I suspect this duping might be caused by bug 290826 comment 8, which is mine. This bug should instead be duped against bug 79130 maybe?

(In reply to comment #8) > I suspect this duping might be caused by bug 290826 comment 8, which is mine. > This bug should instead be duped against bug 79130 maybe? > Maybe they are both symptoms of a common problem; but bug 79130's summary seems "closer" to the symptoms of this bug.