history(5) [suse man page]
HISTORY(5) File Formats Manual HISTORY(5) NAME
history - record of current and recently expired Usenet articles DESCRIPTION
The file <pathdb in inn.conf>/history keeps a record of all articles currently stored in the news system, as well as those that have been received but since expired. In a typical production environment, this file will be many megabytes. The file consists of text lines. Each line corresponds to one article. The file is normally kept sorted in the order in which articles are received, although this is not a requirement. Innd(8) appends a new line each time it files an article, and expire(8) builds a new version of the file by removing old articles and purging old entries. Each line consists of two or three fields separated by a tab, shown below as : [Hash] date [Hash] date token The Hash field is the ASCII representation of the hash of the Message-ID header. This is directly used for the key of the dbz(3). The date field consists of three sub-fields separated by a tilde. All sub-fields are the text representation of the number of seconds since the epoch -- i.e., a time_t; see gettimeofday(2). The first sub-field is the article's arrival date. If copies of the article are still present then the second sub-field is either the value of the article's Expires header, or a hyphen if no expiration date was speci- fied. If an article has been expired then the second sub-field will be a hyphen. The third sub-field is the value of the article's Date header, recording when the article was posted. The token field is a token of the article. This field is empty if the article has been expired. For example, an article whose Message-ID was <7q2saq$sal$1@isrv4.pa.vix.com>, posted on 26 Aug 1999 08:02:34 GMT and recieved at 26 Aug 1999 08:06:54 GMT, could have a history line (broken into three lines for display) like the following: [E6184A5BC2898A35A3140B149DE91D5C] 935678987~-~935678821 @030154574F00000000000007CE3B000004BA@ In addition to the text file, there is a dbz(3) database associated with the file that uses the Message-ID field as a key to determine the offset in the text file where the associated line begins. For historical reasons, the key includes the trailing byte (which is not stored in the text file). HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. This is revision 3782, dated 2000-08-17. SEE ALSO
dbz(3), expire(8), inn.conf(5), innd(8), makehistory(8). HISTORY(5)
Check Out this Related Man Page
EXPIRE.CTL(5) File Formats Manual EXPIRE.CTL(5) NAME
expire.ctl - control file for Usenet article expiration DESCRIPTION
The file /etc/news/expire.ctl is the default control file for the expire(8) program, which reads it at start-up. Blank lines and lines beginning with a number sign (``#'') are ignored. All other lines should be in one of two formats. The first format specifies how long to keep a record of fully-expired articles. This is useful when a newsfeed intermittently offers older news that is not kept around very long. (The case of very old news is handled by the ``-c'' flag of innd(8).) There should only be one line in this format, which looks like this: /remember/:days Where days is a floating-point number that specifies the upper limit to remember a Message-ID, even if the article has already expired. (It does not affect article expirations.) Most of the lines in the file will consist of five colon-separated fields, as follows: pattern:modflag:keep:default:purge The pattern field is a list of wildmat(3)-style patterns, separated by commas. This field specifies the newsgroups to which the line is applied. Note that the file is interpreted in order, so that the last line that matches will be used. This means that general patterns (like a single asterisk to set the defaults) should appear before specific group specifications. The modflag field can be used to further limit newsgroups to which the line applies, and should be chosen from the following set: M Only moderated groups U Only unmoderated groups A All groups The next three fields are used to determine how long an article should be kept. Each field should be either a number of days (fractions like ``8.5'' are allowed) or the word ``never.'' The most common use is to specify the default value for how long an article should be kept. The first and third fields -- keep and purge -- specify the boundaries within which an Expires header will be honored. They are ignored if an article has no Expires header. The fields are specified in the file as ``lower-bound default upper-bound,'' and they are explained in this order. Since most articles do not have explicit expiration dates, however, the second field tends to be the most impor- tant one. The keep field specifies how many days an article should be kept before it will be removed. No article in the newsgroup will be removed if it has been filed for less then keep days, regardless of any expiration date. If this field is the word ``never'' then an article cannot have been kept for enough days so it will never be expired. The default field specifies how long to keep an article if no Expires header is present. If this field is the word ``never'' then articles without explicit expiration dates will never be expired. The purge field specifies the upper bound on how long an article can be kept. No article will be kept longer then the number of days spec- ified by this field. All articles will be removed after then have been kept for purge days. If purge is the word ``never'' then the arti- cle will never be deleted. It is often useful to honor the expiration headers in articles, especially those in moderated groups. To do this, set keep to zero, default to whatever value you wish, and purge to never. To ignore any Expires header, set all three fields to the same value. There must be exactly one line with a pattern of ``*'' and a modflags of ``A'' -- this matches all groups and is used to set the expiration default. It should be the first expiration line. For example, ## How long to keep expired history /remember/:5 ## Most things stay for two weeks *:A:14:14:14 ## Believe expiration dates in moderated groups, up to six weeks *:M:1:30:42 ## Keep local stuff for a long time foo.*:A:30:30:30 HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. This is revision 1.15, dated 1996/10/29. SEE ALSO
expire(8), wildmat(3). EXPIRE.CTL(5)