larry@kitty.UUCP (Larry Lippman) (02/27/86)
A few days ago, I installed news 2.10.3 to replace news 2.10.2 on a
3B2 running System V Release 2.2. This particular news version just came from
seismo, and is supposed to be the most recent and debugged version of 2.10.3.
The conversion went reasonably well, so far I have found no bugs, and the
rnews(inews) and expire functions seem to run MUCH faster than with the 2.10.2
version.
But something is bothering the hell outta me... Since I manually did
the install.sh functions (so as not to wipe out any article data), I had to
create a history directory called history.d, in which the news automatically
installed ten hashed files named ``0'' through ``9''. If I were to remove
this directory, then I would get a duplicate history file line for each article
and expire will barf an error message. With the directory installed, all
functions work okay.
Except that I have seen the 2.10.3 beta version of news installed on
systems running System V, and there is NO history.d directory and history
subfiles. So I read the doc's again.
---
From install.mn document:
history.dir,history.pag
These two files are used on V7 systems as a hashed version of history,
containing the message id's of all articles in history. They are only used if
-DDBM and -ldbm appear in Makefile .
---
No where in my Makefile did I have DBM defined. The localize.usg file
removes the DBM lines from Makefile.dst to create Makefile - which is fine,
since I am not running V7. So I grepped through the source.
---
From expire.c:
#ifndef DBM
/* rebuild history subfiles */
for (i = 0; i < 10; i++) {
(void) sprintf(fn, "%s.d/%c", ARTFILE, i + '0');
close(creat(fn, 0644));
subfd[i] = xfopen(fn, "w+");
}
...
#endif /* !DBM */
---
Now wait a minute! This is contradictory to what the installation
document infers. Other source modules also tell me that I am going to have
the history subfiles even though I am not running V7.
Does anyone know what is going on here???
==> Larry Lippman @ Recognition Research Corp., Clarence, New York <==
==> UUCP {decvax|dual|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry <==
==> VOICE 716/741-9185 {rice|shell}!baylor!/ <==
==> FAX 716/741-9635 {G1, G2, G3 modes} duke!ethos!/ <==
==> seismo!/ <==
==> "Have you hugged your cat today?" ihnp4!/ <==mark@casemo.UUCP (02/28/86)
> > A few days ago, I installed news 2.10.3 to replace news 2.10.2 > on a 3B2 running System V Release 2.2. This particular news version > just came from seismo, and is supposed to be the most recent and > debugged version of 2.10.3. The conversion went reasonably well, > so far I have found no bugs, and the rnews(inews) and expire functions > seem to run MUCH faster than with the 2.10.2 version. In fact, there is more. When I tried to do a rebuild of the history file with 2.10.3, all articles were marked in the history file as being received on the day I ran the rebuild. In addition, it seems that rnews no longer puts the receive date in the article header when the article is received. In 2.10.3 beta, it was this date that expire used when it did the rebuild. If you look at the rebuild code in expire, there is a gaping hole. There is a statement that looks like: if (dorebuild) { .... rectime = cgtdate(recdate); tm = loaltime (&rectime); .... } but I have not yet been able to find where recdate gets set when you are doing a rebuild. In 2.10.3 beta, it was pulled from the article header, but, as I said, rnews no longer puts it there. Now all of this isn't bad unless you mind the news using most/all of your disk. With all articles marked as being received on the same day, it is a matter of about 1-2 weeks before things start getting removed. Any help on this matter would be appreciated. -- ------------------------------------------------------------------------ Mark Hilbush CASE Communications, Inc. decuac!casemo!mark 2120 Industrial Pkwy. (301) 622-2121 Silver Spring, MD 20904-1999
avolio@decuac.UUCP (Frederick M. Avolio) (02/28/86)
Since 2.10.3 news is pretty new, rather than discussing it in this news
group, anyone with problems should drop a note to the person who is
"in charge" of said software.
--
Fred @ DEC Ultrix Applications Center
UUCP: {decvax,seismo,cbosgd}!decuac!avolio INET: avolio@decuac.DEC.COM