lcz@dptspd.sat.datapoint.com (Lee Ziegenhals) (07/17/90)
Several of the maps that I have received lately have had an expiration date that is less than 24 hours after the posting date. This caused the map files to be expired and deleted before pathalias ran. I have modified my crontab so that pathalias runs before my nightly expire. However, I have lost several updates because of the problem. Was this intentional? If so, why do the maps need to be expired so quickly? Aren't the maps generally valid for about a month, and therefore shouldn't the expiration period be about a month? Thanks, Lee Ziegenhals (lcz@sat.datapoint.com)
werner@cs.utexas.edu (Werner Uhrig) (07/17/90)
Lee Ziegenhals) wrote: > Several of the maps that I have received lately have had an expiration date > that is less than 24 hours after the posting date. > shouldn't the expiration period be about a month? maybe what was meant was to expire after 1 month plus one day? it seems 1 month plus 10 days mihgt be better ....
dave@imax.com (Dave Martindale) (07/18/90)
In article <591@dptspd.sat.datapoint.com> lcz@dptspd.sat.datapoint.com (Lee Ziegenhals) writes: >Several of the maps that I have received lately have had an expiration date >that is less than 24 hours after the posting date. This caused the map files >to be expired and deleted before pathalias ran. > >I have modified my crontab so that pathalias runs before my nightly expire. >However, I have lost several updates because of the problem. Was this >intentional? If so, why do the maps need to be expired so quickly? Aren't >the maps generally valid for about a month, and therefore shouldn't the >expiration period be about a month? One very common way of dealing with the maps is to feed them to a processing script via a dummy site entry in the news sys file. For example, (this is an entry for C news, but B news is quite similar): extractmap:comp.mail.maps,!comp.mail.maps.ctl/world,can,local::/var/map/extractmap %s In my case, the "extractmap" script gets rid of the news article header, and places the contents of the article in a standard directory. Because this happens as each article is processed, the copy of the article that ends up in /usr/spool/news is useful only for feeding to other sites downstream; it is not used locally for pathalias. Thus, it can safely be expired in a few days. The advantage of this method is that at any given time, you have a directory full of the most-recently-received version of each map. There are no duplicates due to old unexpired articles. If one of this month's entries did not make it here, last month's is used instead - that's better than having no data at all for a whole contry or province or state. So, I suspect that the rapid expiry date was probably a mistake - the maps should stay around for at least a few days to provide for batched transmission to other sites. But for many sites, the expiry time does not need to be anywhere near a month. How many people run pathalias directly from the news articles in /usr/spool? Is this common?
lcz@dptspd.sat.datapoint.com (Lee Ziegenhals) (07/18/90)
dave@imax.com (Dave Martindale) writes: >One very common way of dealing with the maps is to feed them to a processing >script via a dummy site entry in the news sys file. For example,... This is a good idea, and I may change my processing to use this method. >How many people run pathalias directly from the news articles in /usr/spool? >Is this common? I don't actually run pathalias from the maps in the news spool directory. I use the :F: option in my sys file to keep a list of the incoming maps, and then process them out of the spool directory once per day. The articles are processed and stored into map files in a separate directory at that time. This worked just fine until the other day :-). However, the only reason it's done that way is because it was done that way when I took over.
pleasant@porthos.rutgers.edu (Mel Pleasant) (07/22/90)
The inappropriate expiration dates placed on map file postings began to
occur when a new version of inews with a broken getdate() routine was
installed on Rutgers.EDU (where the maps are posted from). Thanks to many
of you here, the problem was reported quickly and fixed. Those map
postings which contained erroneous dates have been reposted.
-- Mel Pleasant
-- The UUCP Mapping Project
--
Mel Pleasant
{backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnetbill@wrangler.WLK.COM (Bill Kennedy) (07/22/90)
pleasant@porthos.rutgers.edu (Mel Pleasant) writes: [ explains the date glitch and that it's fixed... ] I don't know if anyone else noticed this or got a chuckle out of it. > Mel Pleasant > {backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnet ^^^^^^^^^^ Holy uucp Batman! If rutgers isn't one, where on earth will I find a backbone? :-) :-) :-) -- Bill Kennedy usenet {texbell,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM or attmail!ssbn!bill