dennis@rlgvax.UUCP (Dennis Bednar) (12/28/86)
I have recently noticed that when a 'cancel' control
message is received from the network, that 2.11 news removes
the article in the /usr/spool/news directory, but it
does *not* remove the entry from the /usr/lib/news/history,
history.pag and history.dir files. Probably a bug.
Too bad expire(8) doesn't have an option to remove a particular
article based on the message-ID.
-dennis
--
-Dennis Bednar
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis UUCPrees@apollo.uucp (Jim Rees) (12/29/86)
I have recently noticed that when a 'cancel' control
message is received from the network, that 2.11 news removes
the article in the /usr/spool/news directory, but it
does *not* remove the entry from the /usr/lib/news/history,
history.pag and history.dir files. Probably a bug.
Feature, not a bug. This prevents the article from getting installed if
it comes in again later. Don't know about the 2.11 expire, but mine keeps
the entry in the history file around for a couple of weeks, then deletes it.dennis@rlgvax.UUCP (Dennis Bednar) (01/05/87)
In article <322f30f0.982f@apollo.uucp>, rees@apollo.uucp (Jim Rees) writes: > > I have recently noticed that when a 'cancel' control > message is received from the network, that 2.11 news removes > the article in the /usr/spool/news directory, but it > does *not* remove the entry from the /usr/lib/news/history, > history.pag and history.dir files. Probably a bug. > > Feature, not a bug. This prevents the article from getting installed if > it comes in again later. Don't know about the 2.11 expire, but mine keeps > the entry in the history file around for a couple of weeks, then deletes it. Let me clarify. When an article is cancelled I think the proper thing for the history file is to contain a line either of the form: <7770@gatech.EDU> 12/19/86 04:49 cancelled <7770@gatech.EDU> 12/19/86 04:49 (The two forms may result depending on whether the cancel control message was received before (1st line) or after (2nd line) the actual article being cancelled. This is only a guess though.) However, the history file erroneously says something like: <1355@mit-vax.LCS.MIT.EDU> 01/05/87 12:09 soc.culture.jewish/89 i.e, the article is still pointed to by the history file, but should say "cancelled" or "" instead. -- -Dennis Bednar {decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis UUCP
kre@munnari.oz (Robert Elz) (01/06/87)
In article <308@rlgvax.UUCP>, dennis@rlgvax.UUCP (Dennis Bednar) writes: > Let me clarify. When an article is cancelled I think the proper thing > for the history file is to contain a line either of the form: > > <7770@gatech.EDU> 12/19/86 04:49 cancelled > <7770@gatech.EDU> 12/19/86 04:49 The first of those is from an incoming cancel message when the message to be cancelled has not been seen, the second comes from expiring a message, not cancelling it. > However, the history file erroneously says something like: > > <1355@mit-vax.LCS.MIT.EDU> 01/05/87 12:09 soc.culture.jewish/89 > > i.e, the article is still pointed to by the history file, but should > say "cancelled" or "" instead. This would be too expensive - history files are large, rewriting it for a cancel message would take forever. So, the history file is just left as it was, the code that accesses articles based on the history file knows that if the file named doesn't exist, then the message must have been cancelled. Robert Elz seismo!munnari!kre
rjnoe@uniq.UUCP (Roger J. Noe) (01/07/87)
In article <1387@munnari.oz>, kre@munnari.oz (Robert Elz) writes: > In article <308@rlgvax.UUCP>, dennis@rlgvax.UUCP (Dennis Bednar) writes: > > i.e, the article is still pointed to by the history file, but should > > say "cancelled" or "" instead. > > This would be too expensive - history files are large, rewriting > it for a cancel message would take forever. But then expire will take care of the line when it runs later, since it will not be able to open the file to see if there's an Expires: field or anything else for that matter. Roger Noe ihnp4!uniq!rjnoe Uniq Digital Technologies rjnoe@uniq.UUCP
kre@munnari.oz (Robert Elz) (01/08/87)
In article <226@uniq.UUCP>, rjnoe@uniq.UUCP (Roger J. Noe) writes: > But then expire will take care of the line when it runs later, since it will > not be able to open the file to see if there's an Expires: field or anything > else for that matter. It would, or could, but expire no longer opens every news article, the history file contains info in it as to whether there is an Expires line or not, if there's not, then there's no need to open the article, so expire will never realise that the article has been cancelled, so won't alter the history file. When it really comes time for the original article to expire, then expire will see that it was cancelled some time earlier. Please forget this issue, there's no bug, it all works. kre