dean@coplex.uucp (Dean Brooks) (02/02/91)
After running C-News for a week or so, I noticed something that
seemed like a possible problem.
We had a C-News expire taking place at the sametime that incoming
batches were being dispersed into the /usr/spool/news area. Both
functions seemed to take place fine at the same time...
My question is this; are the two functions compatible with each
other? It would seem that ONE function must have complete control
of the history file. Otherwise, it would seem that articles would
be missing/extra in the history file.
Along the same line, I have noticed that there are articles "staying"
around in /usr/spool/news past the expiration delay time.
I have the "/bound/" entry in explist set to "0-1-31", the "/expire/"
entry set to 14 days, and the only other line expires ALL articles at
the value of "5" (min/max bounds are taken from the "/bound/" line.
Is there any collision I should check for that may cause history
to contain the wrong information (that could screw up expiring). I
really dont want to have articles staying around forever, as that was
one reason I switched to C-News...
Any experienced C-News hacks have any suggestions? Thanks...
--
dean@coplex.UUCP Dean A. Brooks
Copper Electronics, Inc.
Louisville, Ky
UUCP: !uunet!coplex!deanhenry@zoo.toronto.edu (Henry Spencer) (02/03/91)
In article <1991Feb2.064711.10702@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes: > We had a C-News expire taking place at the sametime that incoming >batches were being dispersed into the /usr/spool/news area. Both >functions seemed to take place fine at the same time... > > My question is this; are the two functions compatible with each >other? It would seem that ONE function must have complete control >of the history file. Otherwise, it would seem that articles would >be missing/extra in the history file. Nope. It is quite safe for the two operations to be done simultaneously. The strategy is subtle but bulletproof. Note that expire builds a new history file rather than modifying the old one, while article reception appends to the history file rather than modifying it in more general ways. The only time exclusive control is needed is when expire hits EOF in the old history file, at which point it has to shoo everyone else away for a moment while it rearranges files. > Along the same line, I have noticed that there are articles "staying" >around in /usr/spool/news past the expiration delay time. > > I have the "/bound/" entry in explist set to "0-1-31", the "/expire/" >entry set to 14 days, and the only other line expires ALL articles at >the value of "5" (min/max bounds are taken from the "/bound/" line. Where are the articles, and how long are they around? And did you misspell "/bounds/" by leaving out the "s", or was that just a typo in your posting? (Hmm, expire doesn't check for unknown /thing/s; this will be fixed.) Are the articles in the history file? (Newshist can tell you that, if you don't want to wait for egrep to run through the whole file.) > Is there any collision I should check for that may cause history >to contain the wrong information (that could screw up expiring)... None known, barring the possibility of anomalies due to a crash. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry