103012 - Update of subscribed newsgroups stops if some newsgroups are empty

Status: VERIFIED FIXED

(MailNews Core :: Networking: NNTP, defect)

Description

[Warwick Hunter]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091323

We have an internal newsgroup server. Some of the newly created newsgroups where
empty and some were not. When Mozilla went to update the unread count it would
update all of the groups until it hit one with an empty message count and then stop.

I added a message to each of the empty newsgroups and the process now works
properly.


Reproducible: Always
Steps to Reproduce:
1. Subscribe to newsgroups that are not empty
2. Subscribe to newsgroups that ARE empty
3. Subscribe to newsgroups that are not empty
4. Collapse and expand the folder in the tree view


Actual Results:  The unread count for the groups after the empty ones are not
updated

Expected Results:  The unread count for the groups after the empty ones should
have been updated

We use a news server replication product called dnews

telnet dnews 119

200 ... DNEWS Version 5.5c6, S0, posting OK

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

Confirming.

Comment 2

[Jean-Pierre Melkonian]

I confirm also. Mac OS 9.1 Build 2002071808

Comment 3

[Frank Widmaier]

windows too

Comment 4

[Boris 'pi' Piwinger]

Setting OS=All by previous comments and additional report (to be included here)
in news:de.comm.software.mozilla. I think this is a normal bug (not minor).

Probably, this is the wrong component. Over to NNTP.

pi

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 164957 has been marked as a duplicate of this bug. ***

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

Warwick, if you create a log, does it look something similar to the snippet I've
included in the comments below?  Thanks.

According to: http://www.ietf.org/rfc/rfc0977.txt

3.2.2.  Responses

   211 n f l s group selected
           (n = estimated number of articles in group,
           f = first article number in the group,
           l = last article number in the group,
           s = name of the group.)
   411 no such news group

So this means in your case:

0[2742d8]: (26e1a80) Receiving: 211 0 103 102 nz.org.net-society

It has a zero-length of articles in the group (estimated), followed by 2
numbers: the first article number (103) and the last article number (102), then
of course the requisite name of the newsgroup.

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 168005 has been marked as a duplicate of this bug. ***

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 150869 has been marked as a duplicate of this bug. ***

Comment 9

[[e-mail] (gone - use [e-mail] instead)]

It also seems like bug 146751 is closely related to or a DUP of this.

Comment 10

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

should be a simple fix, working on it...

Comment 11

[Stuart Summerville]

I'd argue your definition of the problem:

Old:
> When Mozilla went to update the unread count it would update all of the groups
> until it hit one with an empty message count and then stop.

When Mozilla went to update the unread count it would update all of the groups
until it hit one with a *zero unread message count* and then stop.

My test case (based on bug 168005 that just got marked as a dup of this one) has
say 10 groups, all with many messages (mostly) marked read, and it seems to stop
at the first group with zero unread messages. Is that not different to what
you're seeing?

And another thing... it doesn't actually *stop* updating the groups according to
the status bar - just that the unread messages indicator for each group isn't
updated.

sTu.

Comment 12

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

Attachment: let's be a little more gracious when the server sends us something we don't expect

Comment 13

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

fixed.

logged on 10-3-2001.  Only took me about a year.  Sheesh.

As stephen will tell you, news gets very little love.

Comment 14

[David G King]

Seth, thanks for the fix. I'll be checking this once I download a nightly tomorrow.

Comment 15

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 146751 has been marked as a duplicate of this bug. ***

Comment 16

[David G King]

Works fine with 20020927 trunk build.

Again thanks to Seth and Stephen.

Marking VERIFIED.

Comment 17

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

david:  thanks for verifying.

Comment 18

[Stuart Summerville]

*** Bug 168005 has been marked as a duplicate of this bug. ***