🚀 go-pugleaf

In article <25734@wash.demon.co.uk>
           john@wash.demon.co.uk "John Washington" wrote:

>This is d.i.developers, not d.i.newusers, so I expect we've all
>read the relevant RFCs.

Having a bad day, John?  This isn't like you normally...

>Rather like batch.txt.  Users don't seem to go around
>deleting that, so I don't see why you might fear them
>deleting intermediate mail files.

I think the fear was of it crashing before the file had been renamed to
something sensible (5FA6CB4A.TMP or whatever tmpfile creates isn't a
very obvious name to look for mail!).

>Actually, far from avoiding a lot of complexity, I would suggest
>it currently has a small amount of extra complexity, namely the coding
>to copy from the temp file to append to the .txt file(s).
>
>If this were moved into a small post-processor (much in the
>spirit of Snews unbatch), I'd expect ka9q to be very slightly
>smaller and a bit quicker.  Perhaps not a sufficient gain to
>make it worth the effort though.

Significant in time, I suspect, especially when appending to a very big
<user>.txt file.  Of course, it would also use more space on machines
with large cluster sizes.

>However, as Graham usefully pointed out, the temp file
>creation is done by a Borland library routine (I didn't
>know that).  So replacing that might indeed require some
>more complexity.  Though making a filename out of a ka9q
>process id or similar doesn't sound difficult.

Easy enough - replace it by tmpname and open (are KA9Q process IDs
uniqueue once the process has died?  Not that it matters, because it's
only a temporary file, just curious).

.-------------------------------.-------------------------------------.
|    chris@keris.demon.co.uk    |  FIAWOL (Filking Is A Way Of Life)  |
`-------------------------------^-------------------------------------'