wales@valeria.cs.ucla.edu (Rich Wales) (04/12/90)
For some time now, we (UCLA CS Dept.) have been plagued by an RN bug that -- under circumstances not clearly understood -- marks articles as read which have not in fact been read. This happens in the course of ordinary reading of articles in a news- group via "^N". It usually (always?) occurs in conjunction with the "Skipping..." message from RN. One minute, there may be several dozen (or even several hundred) unread articles in a newsgroup; the next thing the user knows, there are only a few unread articles, or even none at all. We are currently running a version of RN with the following header: $Header: rn.c,v 4.3.2.2 89/11/28 01:51:25 sob Locked $ Also, we are using NNTP to access articles from a local server. Does anyone else experience this same problem? Is there a fix for it? -- Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "I never lie when I've got sand in my shoes, Commodore."
dave@imax.uucp (Dave Martindale) (04/13/90)
In article <34104@shemp.CS.UCLA.EDU> wales@valeria.cs.ucla.edu (Rich Wales) writes: >For some time now, we (UCLA CS Dept.) have been plagued by an RN bug >that -- under circumstances not clearly understood -- marks articles >as read which have not in fact been read. > >This happens in the course of ordinary reading of articles in a news- >group via "^N". It usually (always?) occurs in conjunction with the >"Skipping..." message from RN. One minute, there may be several dozen >(or even several hundred) unread articles in a newsgroup; the next >thing the user knows, there are only a few unread articles, or even >none at all. This *will* occur, and is perfectly normal, if articles expire before you've read them. When you select a group, rn looks at what articles you've already read (according to the .newsrc) and declares the rest of them to be "unread". Then, when you start reading, rn may find that many of those articles do not exist, thus the "skipping" message. When rn finally finds a "next article" that is really present, you may find that it has revised its idea of how many articles remain to be read. The "lost" articles were unread by that user, but do not exist locally, so rn marks them read. Now, the "active" file contains a field that tells you the lowest article number still present, and this may modify rn's idea of the lowest possible unread article. But C news sites don't necessarily update the active file as frequently as they expire articles. And, in any case, one particular article with a far-future explicit expiry date will cause the "lowest unexpired article" field to stay static while hundreds of articles after it have expired.
wales@valeria.cs.ucla.edu (Rich Wales) (04/14/90)
In article <34104@shemp.CS.UCLA.EDU> I wrote:
For some time now, we (UCLA CS Dept.) have been plagued by an
RN bug that -- under circumstances not clearly understood --
marks articles as read which have not in fact been read.
This happens in the course of ordinary reading of articles in a
newsgroup via "^N". It usually (always?) occurs in conjunction
with the "Skipping..." message from RN. One minute, there may
be several dozen (or even several hundred) unread articles in a
newsgroup; the next thing the user knows, there are only a few
unread articles, or even none at all.
Several people have replied to me -- most of them suggesting that what
I'm seeing is simply the normal situation where RN realizes that some
articles have expired and no longer exist.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ I am aware of this issue, but it is =NOT= what I am seeing. +
+ +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In our case, the articles RN is throwing away are still on the local
server host. Their subject lines show up if the user does a "=" command
(before RN decides to skip them, that is). And, even after RN decides
to skip the articles in question, one can still read these articles by
typing their numbers explicitly.
One person suggested to me that perhaps we're having a problem with
"expire" not being in sync with the articles on disk; that is, that the
articles in question have really expired but were never removed. The
next time the RN bug bites me :-{, I'll take a look to see if this might
be the explanation.
Also, I realize that we are not running the very latest version of RN.
Before we upgrade, though, it would be nice to know whether the newer
version claims to address our problem. So far, it doesn't appear to.
Finally, is there any way to create a transcript of the NNTP commands
that go back and forth between RN and the NNTP daemon? If I could do
this, then when the bug bit I could go back and review the NNTP dialog.
-- Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683
"I never lie when I've got sand in my shoes, Commodore."