Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!cs.utexas.edu!uunet!ssbell!kent
From: kent@ssbell.UUCP (Kent Landfield)
Newsgroups: comp.sources.d
Subject: Re: A few questions/comments on Rkive
Keywords: long rkive archive sources USENET
Message-ID: <525@ssbell.UUCP>
Date: 14 Jul 89 15:52:50 GMT
References: <1123@ssp15.idca.tds.philips.nl> <520@ssbell.UUCP> <1989Jul7.022708.4826@eci386.uucp> <523@ssbell.UUCP> <1989Jul13.160050.3478@eci386.uucp>
Reply-To: kent@ssbell.UUCP (Kent Landfield)
Organization: Sterling Software, FSG-IMD, Bellevue, NE.
Lines: 42

In article <1989Jul7.022708.4826@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes:
# Actually, what might be better (from the point of view of trying to
# collect lots of articles before bothering the MAIL: people) is to parse
# a batch file.  For example, I have the following (C-news) sys file entry:
# 
#     maps:comp.mail.maps/all:f:
# 
# Which places the file name of each article in comp.mail.maps, and I
# have a cron entry that runs a script that pulls each file name out
# and unpacks it, calls pathalias and sends mail to me.  

In article <1989Jul13.160050.3478@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes:
# The main advantage is that you don't have to rummage around in the directory,
# possibly parse the files, and check your database to see whether you've
# already unpacked it.  You know that every single file listed in the batch
# is new and you've not seen it before.  In fact, with this approach you 
# NEVER* have to have rkive reread its own databases or scan directories - 
# the index files are merely logs of what things rkive's already snarfed, and
# the batch file is names of files that rkive hasn't read yet.  

Now I see what you meant. With this approach the .archived file could become
history.. :-) Currently, rkive reads the directory to get a file name and
then reads the .archived file to see if it has been already been archived.
If the filename is not found in the .archived file, the file is archived. With
your approach, I would not need to do that check...  Sorry, I'm just a little
slow some times... :-)

In article <523@ssbell.UUCP> I wrote:
# I made this a compile time decision by adding
# an ifdef around the getpwnam call.

Chris writes:
>Oops, I musta missed that somewhere.

No you didn't. That change is in the patch being posted today.

			-Kent+
---
Kent Landfield               UUCP:     kent@ssbell
Sterling Software FSG/IMD    INTERNET: kent@ssbell.uu.net
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362