Path: utzoo!attcan!uunet!jarthur!usc!ucla-cs!wales From: wales@valeria.cs.ucla.edu (Rich Wales) Newsgroups: news.software.b Subject: RN bug -- throws away unread articles (clarification) Message-ID: <34184@shemp.CS.UCLA.EDU> Date: 13 Apr 90 18:29:25 GMT References: <34104@shemp.CS.UCLA.EDU> Sender: news@CS.UCLA.EDU Reply-To: wales@CS.UCLA.EDU (Rich Wales) Organization: UCLA CS Department, Los Angeles Lines: 46 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 // 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."