Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caesar.cs.montana.edu!caesar!icsu6000
From: icsu6000@caesar (Jaye Mathisen)
Newsgroups: news.software.b
Subject: Re: What If...I remove "/usr/lib/news/history*" ?
Message-ID: <3459@caesar.cs.montana.edu>
Date: 4 Mar 90 05:57:34 GMT
References: <490@limbo.Intuitive.Com>
Sender: news@caesar.cs.montana.edu
Reply-To: icsu6000@caesar.cs.montana.edu (Jaye Mathisen)
Organization: Montana State University, Dept. of Computer Science, Bozeman MT 59717
Lines: 75

In article <490@limbo.Intuitive.Com> taylor@limbo.Intuitive.Com (Dave Taylor) writes:
>What if I were to remove the following files from /usr/lib/news ?
>	history
>	history.dir
>	history.pag
>As far as I am aware -- and keep in mind that the only news reader
>we have installed on this site is "rn" -- the only purpose that the
>files serve are to ensure that duplicate articles aren't allowed.
>Am I right?  (I have heard some reference to commands in "rn" that




This would result in near-disaster.  No duplicate checking, and
expire would have a tough time running.




>indication of how many lines are contained therein.  To unpack,
>simply put the article into its own temp file, check its MessageID
>against those already on the machine, then if unique, add it to the



Where are you going to store Message-ID's...  That's one of the
functions of history.*




>Really what I'd like to do is to write an unpacker that will 
>immediately throw away articles from groups that appear/don't appear
>in a file.  The goal would be to have the file generated via a modified
>pexpire(1L) program to reflect JUST the groups that people are actually
>actively reading on the machine.  ALL other articles would vanish 



How do you handle the case of looking through comp.archives, and finding
that there's this interesting thingie in group x, but since nobody subscribes
to group x, the spooled article isn't there to find any more info...




>This all really hinges around the history file, though.  Clearly, when
>my expires take many many hours to run, it's because they're munging



Well, I don't know what hardware you're using (I think HP from a previous
posting :-)), but I keep 2 weeks of Usenet, plus every alternative hierarchy
I can lay my hands on, using a HP350, and expire cranks through nightly
in about 2.5 hours...  



>through the slow and painful process of continually updating the DBM
>history database ... (right?) ... I mean, I can run "fixactive(1L)"

In a nutshell, expire creates a new history file each nite, after making
one run through the history.* files, and unlinking expired articles.  It
names it nhistory.{dir,pag} while creating it, and then renames it to
history.{dir,pag}  etc.  

There's a sort in there somewhere also.



--
+-----------------------------------------------------------------------------+
| Jaye Mathisen,systems manager       Internet: icsu6000@caesar.cs.montana.edu|
| 410 Roberts Hall                      BITNET: icsu6000@mtsunix1.bitnet      |
| Dept. of Computer Science	                                              |