Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watcgl.UUCP
Path: utzoo!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.news.group
Subject: Re: New newgroup suggestion--Re: Permanent Postings
Message-ID: <859@watcgl.UUCP>
Date: Thu, 27-Dec-84 00:09:50 EST
Article-I.D.: watcgl.859
Posted: Thu Dec 27 00:09:50 1984
Date-Received: Thu, 27-Dec-84 03:45:10 EST
References: <852@watcgl.UUCP> <1043@houxm.UUCP>
Reply-To: dmmartindale@watcgl.UUCP (Dave Martindale)
Organization: U of Waterloo, Ontario
Lines: 66

In article <1043@houxm.UUCP> gregbo@houxm.UUCP (Greg Skinner) writes:

>Let me clarify.
>
>If you want to have articles that *never* expire, you can use cron to keep them
>around.  We do nightly expires of netnews.  The lines in crontab are something
>like:
>
>touch /usr/spool/news/net/announce/newusers/* 
>cd /usr/spool/news
>find . -mtime +14 -exec rm {} \;
>
>Before executing these two lines, the desired files which can be kept are just
>touched, thereby the find ignores them.  I've seen it posted by Mark Horton
>that the find(1) method of expiring news articles is nonstandard, but it seems
>to work for us pretty well.  We are pretty much forced to do this, otherwise
>/usr tends to run out of space on our machines.

Ok, now I see that you didn't understand what I was talking about, so I'll
expand a bit:
With older versions of news (before 2.10.2) there was an "expire"
program that most sites used to delete old news articles.  If an
article lacked an "Expires:" header line, it was deleted after a
certain default expiry period; if the Expires header was present, that
date was used instead.  This is generally a useful feature, since it
allows you to have articles that expire when they are really no longer
useful (the announcement about the birthday tomorrow can expire
tomorrow night, while the film schedule for the local repertory cinema
can remain around for the whole month it covers).  And expire performs
a housekeeping task too - it cleans up the "history" file, deleting
entries for articles that have expired.

The method of using "find" as you have certainly does delete old news,
and probably runs faster than expire since it doesn't need to open
every article looking for an Expires: line, but you lose the housekeeping
functions.

In 2.10.2 news, you simply must use "expire".  As well as housecleaning
the history file, it also updates the active file, which has been
expanded to include a field which is the article-number of the lowest-
numbered unexpired article in the newsgroup.  If you don't run
expire, (or if you do run it and some article never expires, which is
what my original article was about) the numerical distance between this
lowest-article-number and the number of the most recently-received article
eventually reaches the point where "readnews" will become upset and quit
if you ever try to read that group.

The reason for the difference in behaviour is that older versions of news
used a large bitmap (8K bits) with an origin of 0 or 1 to keep track of
articles that have been read, and thus couldn't handle article-numbers
greater than 8192 at all.  2.10.2 news uses a smaller bitmap (2K bits I
think) but with an origin of the first unread article present in
the group, which is obtained from the active file.  So, it can handle
almost arbitrarily-large article numbers, but only if the difference
between the oldest and newest unexpired article numbers is under 2K.

Does this make sense now?

By the way, our crontab entry for expiring news looks like:
30 6 * * * su news -c "exec /usr/lib/news/expire -e 14 -v >! /usr/tmp/expire" >/dev/console 2>&1
where the useful part is the "expire", "-e 14" sets the default expiry
for this machine to 14 days rather than the campus-wide compiled-in value
of 28, and the -v just produces a listing of what it did in /usr/tmp/expire
so I can look at it later if I want.  The other stuff makes sure it is run
as a non-root process and sends any error messages to a place where they
may be seen.