Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!orion.cf.uci.edu!uci-ics!nagel@paris.ics.uci.edu
From: nagel@paris.ics.uci.edu (Mark Nagel)
Newsgroups: news.software.nntp
Subject: Re: Bug in GROUP command ?
Message-ID: <18381@paris.ics.uci.edu>
Date: 21 Jun 89 04:05:38 GMT
References: <2692@chorus.fr>
Sender: news@paris.ics.uci.edu
Reply-To: nagel@paris.ics.uci.edu (Mark Nagel)
Organization: University of California, Irvine - Dept of ICS
Lines: 25
In-reply-to: dp@adagio.chorus.fr (Didier Poirot)

In article <2692@chorus.fr>, dp@adagio (Didier Poirot) writes:

|	I think there is a bug in the GROUP command:

|If there is a new article posted in the concerned group  between the 2 
|calls, the second call gives me the same results as the first !! 
|I have to close the server, and to start it again to get the right answer.

I don't think it is a bug, but it is unfortunate.  Another change for
the new RFC?  Or was there some rationale for doing it this way?  I
don't recall seeing any in RFC 977.

| I have made a little mod. in group.c to call read_groups() if the stat()
|of the active file has changed since the last invokation of the command.
|It slow down  a little when I enter the GROUP command, but now I have the right result. It is more faster than closing then starting the server.

If your patch isn't huge, I'm sure many people would appreciate seeing
it here (I would!).  Since this is a pretty transparent type of
change, I think it should at least be an option in conf.h in the next
official patch...

Mark Nagel @ UC Irvine, Department of Information and Computer Science
                            +----------------------------------------+
ARPA: nagel@ics.uci.edu     | N = 1 implies P = NP                   |
UUCP: ucbvax!ucivax!nagel   |                                        |