Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!gatech!arthur.cs.purdue.edu!spaf
From: spaf@uther.cs.purdue.edu (Gene Spafford)
Newsgroups: news.admin,news.sysadmin,news.software.b
Subject: Re: Help- expire problem
Message-ID: <2111@arthur.cs.purdue.edu>
Date: Thu, 22-Oct-87 10:09:47 EDT
Article-I.D.: arthur.2111
Posted: Thu Oct 22 10:09:47 1987
Date-Received: Sun, 25-Oct-87 01:15:30 EDT
References: <170@bnl.ARPA>
Sender: news@arthur.cs.purdue.edu
Reply-To: spaf@uther.cs.purdue.edu.UUCP (Gene Spafford)
Organization: Department of Computer Science, Purdue University
Lines: 65
Summary: How expiration times work
Xref: mnetor news.admin:1221 news.sysadmin:421 news.software.b:899

In article <170@bnl.ARPA> abrams@bnl.UUCP (Karl L. Abrams) writes:
>[...]
>When an article is due to expire, it is removed from the spool, but its
>entry in history is only partially removed.  For example, before expire:
>
><1906@arthur.cs.purdue.edu>	Sep 18 00:13	news.announce.newusers/63 
><1907@arthur.cs.purdue.edu>	Sep 18 00:13	news.misc/693 news.config/222 
>and after expire runs:
><1906@arthur.cs.purdue.edu>	Sep 18 00:13	
><1907@arthur.cs.purdue.edu>	Sep 18 00:13	
>
>All articles older than 14 days have this done to them, and the history file
>is growing longer every day.

This is *exactly* how news 2.11 is supposed to behave!

There are basically 2 expirations going on with the history file.  One
is controlled by the DFLTEXP define in the defs.h file, and this
defines how long before the article body remains on disk before it is
deleted by expire.  The normal expiration period is 2 weeks, although
many sites set that higher or lower depending on local disk capacity.

The second expiration limit is controlled by the HISTEXP define.  This
governs how long the information about an article (basically the
article ID and time of arrival) remains in the history file.  The
distributed default on this is 4 weeks, and it should always be longer
than the DFLTEXP value.

If an article arrives at your site and the article ID is in the history
file, the article is rejected (your site has already received it).  If
that information is not kept and a copy of the article reaches your
machine after the expiration, the article would appear again at your
machine (and your machine would again forward it to your neighbors). By
keeping the information in the history file after the article has been
expired from disk, it helps keep "time warps" from occurring and old
articles from reappearing on your system.  It also enables sites like
arthur.cs.purdue.edu to have expiration periods of 4 days (due to very
constrained disk space) and not end up getting articles multiple times
due to normal Usenet propagation delays.

After HISTEXP has passed, those entries will be deleted from your
history file -- it will not grow boundlessly.

Three asides on this:

   1) Other, similar entries can appear in your history file -- in
      cases where you get a 'cancel" message before the actual article
      arrives, the ID is put in the history file to cause the article
      to be discarded when it does arrive.

   2) using "expire -r" removes all the HISTEXP entries when it
      rebuilds the history file.  As such, it should only be used if
      the history file gets totally trashed.  The "expire -h" form
      ignores the history file when looking for articles to expire, but
      preserves the HISTEXP information.  I recommend using this once
      every 1 to 2 weeks.

   3) The -e option to expire can be used to override the DFLTEXP
      value, and the -E option can be used to override the HISTEXP
      option.

-- 
Gene Spafford
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf