🚀 go-pugleaf

In article <1990Aug11.031724.11712@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
| In article <15112@.la.locus.com> geoff@ITcorp.com (Geoff Kuenning) writes:
| >The only problem I can see with this scheme is that expire, upon seeing
| >that an article has disappeared, might not keep the message-ID around for
| >duplicate-prevention purposes.  My guess is that this is similar to
| >cancelled messages, and thus not a problem, but I haven't investigated
| >personally.  Do Henry or Geoff care to comment?

| I cannot speak for B News expire, but C News expire does not even look to
| see whether the article exists until it's time to expire it.  And even then,
| if it's missing, C expire just says "hmph, must have been cancelled", and
| carries on.  Cancellation removes the article but does not affect the
| history file, because it's seriously painful to alter a history-file
| entry that is already in place, and it's not worth the trouble.

B-news expire works in more-or-less the same fashion.  Manually removing
an article doesn't affect the history, even after the article would
normally have been expired.

That is, under normal usage.  If you do
an "expire -r" (rebuild database), expire doesn't look at the history
file at all, and any articles no longer there have their history entries
discarded.  Which is why it ain't a good idea to run B-news expire unless
you're convinced that it's lost a lot of entries.
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list
Psroff information/questions: psroff-request@eci386