185972 - Last message from group range missing is never updated

Status: RESOLVED DUPLICATE of bug 79130

(MailNews Core :: Networking: NNTP, defect)

Description

[Boris 'pi' Piwinger]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021122

I am observing this bug for a very long time, but never worked it out. Now I did
investigate and found the following:

When you have a newsgroup where the last message (as given by the group command)
is missing (nothing returned by xover), there will alway be an unread count of
at least one. If you mark the group as read this goes down to zero, but the next
update brings it back.

Here are the details. Let me first show you the situation as observed with telnet:

[3.14@pi ~]$ telnet news.univie.ac.at 119
Trying 131.130.1.118...
Connected to news.univie.ac.at.
Escape character is '^]'.
200 news.univie.ac.at NNRP Service Ready - [e-mail] (posting ok).
MODE READER
200 news.univie.ac.at NNRP Service Ready - [e-mail] (posting ok).
GROUP de.comm.provider.usenet
211 666 11167 11832 de.comm.provider.usenet
xover 11832
224 data follows
.
quit
205 Transferred 236 bytes in 0 articles, 1 group.  Disconnecting.
Connection closed by foreign host.

So you see that the group contains messages 11167-11832, but the last does not
exist anymore (probably cancelled).

Now let's see what Mozilla does (from nntp log, I reduce to the interesting part):

First I open (expand) this news server:

1024[80896e0]: (8dff020) Receiving: 200 news.univie.ac.at NNRP Service Ready -
[e-mail] (posting ok).
1024[80896e0]: (8dff020) Next state: NNTP_LOGIN_RESPONSE
1024[80896e0]: (8dff020) Next state: NNTP_SEND_MODE_READER
1024[80896e0]: (8dff020) Sending: MODE READER
1024[80896e0]: (8dff020) Next state: NNTP_RESPONSE
1024[80896e0]: (8dff020) Receiving: 200 news.univie.ac.at NNRP Service Ready -
[e-mail] (posting ok).
1024[80896e0]: (8dff020) Next state: NNTP_SEND_MODE_READER_RESPONSE
1024[80896e0]: (8dff020) Next state: SEND_FIRST_NNTP_COMMAND
1024[80896e0]: (8dff020) Next state: NEWS_DISPLAY_NEWS_RC
[various groups]
1024[80896e0]: (8dff020) Sending: GROUP de.comm.provider.usenet
1024[80896e0]: (8dff020) Next state: NNTP_RESPONSE
1024[80896e0]: (8dff020) Receiving: 211 666 11167 11832 de.comm.provider.usenet
1024[80896e0]: (8dff020) Next state: NEWS_DISPLAY_NEWS_RC_RESPONSE
1024[80896e0]: (8dff020) Next state: NEWS_DISPLAY_NEWS_RC
1024[80896e0]: (8dff020) Next state: NEWS_DONE
1024[80896e0]: (8dff020) Next state: NEWS_FREE

OK, now I click on the group de.comm.provider.usenet, at this time one new
message is displayed:

1024[80896e0]: (8dff020) ParseURL
1024[80896e0]: (8dff020) fullPath = /de.comm.provider.usenet
1024[80896e0]: (8dff020) m_messageID = (null)
1024[80896e0]: (8dff020) group = de.comm.provider.usenet
1024[80896e0]: (8dff020) commandSpecificData = (null)
1024[80896e0]: (8dff020) m_key = -1
1024[80896e0]: (8dff020) Next state: SEND_FIRST_NNTP_COMMAND
1024[80896e0]: (8dff020) Sending: GROUP de.comm.provider.usenet
1024[80896e0]: (8dff020) Next state: NNTP_RESPONSE
1024[80896e0]: (8dff020) Receiving: 211 666 11167 11832 de.comm.provider.usenet
1024[80896e0]: (8dff020) Next state: SEND_FIRST_NNTP_COMMAND_RESPONSE
1024[80896e0]: (8dff020) Next state: SETUP_NEWS_STREAM
1024[80896e0]: (8dff020) Next state: NNTP_XOVER_BEGIN
1024[80896e0]: (8dff020) SetCurrentGroup to de.comm.provider.usenet
1024[80896e0]: (8dff020) Next state: NNTP_FIGURE_NEXT_CHUNK
1024[80896e0]: (8dff020) Next state: NEWS_PROCESS_XOVER
1024[80896e0]: (8dff020) Next state: NEWS_DONE
1024[80896e0]: (8dff020) Next state: NEWS_FREE

Too bad the log file does not show the actual dialog, but it must have sent
XOVER to the server and received nothign for the last message. Anyhow, the
unread count is still at one, but no message is found as unread. So I press mark
group read. Then I collapse and expand the server again. The log looks exactly
like the the first time above.

Here is what newsrc-news.univie.ac.at has to say about the group in question
(after closing Mozilla, just to be sure it is finally written):
de.comm.provider.usenet: 1-11831

As you can see, the last number is too small. It should have been updated on
XOVER or at the latest on mark group read.

There is nothing I can see to repair the unread count for the user. The only
solution is to manually repair the .newsrc. Hence marking major.

pi

Comment 1

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 2

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 3

[Joshua Cranmer [:jcranmer]]

Boris, do you still see this problem in TB 2.0.0.* or recent Trunk TB builds? If no response in 3 weeks, I will close this bug as INCO.

Comment 4

[Boris 'pi' Piwinger]

I no longer use SeaMonkey for news. But I have given clear explanation how you can reproduce the exact situation which causes the problem. So you can test it.

pi

Comment 5

[Joshua Cranmer [:jcranmer]]

It's difficult to actually test problems with expired messages. In lieu of any better information, duping to 79130.

Comment 6

[Boris 'pi' Piwinger]

It does not depend on a particular message, but on a specific situation as described. Having said that the dupe sound right.

pi