294754 - "Phantom" news messages when cancelled before being read, newsgroup won't stay "read"

Status: VERIFIED DUPLICATE of bug 79130

(Thunderbird :: General, defect)

Description

[Tony Mechelynck [:tonymec]]

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.

Comment 1

[Tony Mechelynck [:tonymec]]

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.

Comment 2

[Victor Kazmirenko]

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

Comment 3

[Tony Mechelynck [:tonymec]]

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.

Comment 4

[Victor Kazmirenko]

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.

Comment 5

[Tony Mechelynck [:tonymec]]

(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. ;-) )

Comment 6

[Jesse Houwing]

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 ***

Comment 7

[Tony Mechelynck [:tonymec]]

(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.

Comment 8

[Rimas Kudelis [use needinfo to ping]]

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?

Comment 9

[Tony Mechelynck [:tonymec]]

(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.