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.