Closed Bug 261495 Opened 20 years ago Closed 19 years ago

Incomplete message retrieval and threading in some groups on giganews.com servers

Categories

(MailNews Core :: Networking: NNTP, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: randys, Assigned: sspitzer)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

I use the Mozilla suite for my newsreader on both Windows 2000 and Debian
GNU/Linux. Everything works fine on Windows 2000, but on Debian, some groups do
not show all messages on the giganews.com servers. For example, on
<news:alt.pets.ferrets> it shows 410 messages available, all old messages with
the newest dated 2003-07-11, and the threading is messed up in that when I
expand a thread I see copies of the first message in the thread. Everytime I
collapse and expand it it adds another copy. This happens on all the giganews
servers I've tried. If I connect to my ISPs server
<nntp://newsgroups.bellsouth.net>, everything is fine. There are 1204 messages
and the threading is fine. I've tried different versions of Mozilla. I've also
tried wiping out the old profile data and reinstalling. All without success.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
have you tried the most recent 1.8a4 builds? I fixed some threading problems
early   this week. For the fix to take effect, you do need to delete the .msf
files for the newsgroup(s) in question.
I just tried the latest nightly with the same results. I `rm -rf /opt/mozilla`,
`rm News/text.giganews.com.msf` and `rm News/text.giganews.com/*.msf`.

I contacted giganews.com. They verified the problem: (Ticket 61749)

  I too see the same thing when I load "alt.pets.ferrets" into
  Mozilla Thunderbird, but not when I use XNews.

  I am escalating this to our engineers so they can look into it,
  but since the problem may be with Mozilla Thunderbird...

Just to update the details: After upgrading to the latest nightly, I expanded
the list of groups under <text.giganews.com>. It showed what appeared to be a
correct number of unread messages (5 digit number). When I clicked on the group
it only loaded 204 messages. I selected another folder and then selected the
same group again and it showed 408 unread messages. Same thing again and it
shows 612 messages. They're duplicates of the first 204. Other details are same.
This occurs in several but not all groups on the giganews servers. The latest
message is about a year old, etc.

I don't know if it helps, but I've put the headers of the first and last message
listed in alt.pets.ferrets from the giganews server at
<http://thepierianspring.org/headers>.

I'm not sure why I get different behavior under Windows. The only difference I
can think of would be that the Windows installation is far older. Could there be
something in the msf file on Windows that allows it to work? I'll check that
tomorrow; I don't have the Windows system in front of me.

Anything else I can check?
I have been able to verify that the same behavior happens on Windows with a
fresh install of Mozilla, having deleted the old profile. So, something about
the profile on my work computer (I won't have access until Tues.) allows it to
function correctly, retrieving recent postings...

I don't understand why something in the profile might affect this behavior.
Anything specific I should look for?

BTW, this behavior has been present since at least 1.4, possibly earlier; I was
just lazy about reporting it.

I'd be willing to pay for a temp giganews account for someone to fix this if it
would help.

Thanks.
This issue has been resolved on Giganews' side. I asked for the details so that
I could report back here. They responded:

<quote>
With headers of an article very line ends with CRLF. You do not usually see this
in the headers that your newsreader shows you. In one older article the line
ended properly with a CRLF, but there were LFs embedded in it as well. I don't
know why Mozilla stopped parsing; at worse it should have reported a few corrupt
lines and then continued with the next. Unfortunetly it didn't. The Giganews
software was changed to filter these awhile back but there are still a few older
messages out there with them.

This was discovered by one of our engineers who fixed the headers of the
particular post.
</quote>
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.