PE> Polyxarc is available on my BBS, comes with C source code,
PE> works under MSDOS, OS/2 and AmigaDos, is public domain,
PE> and will unarchive mail packets and then (if you want),
PE> automatically delete the original archive if it was successful.

I've been thinking about it, but its got some real problems.
The only real problem with using PKUNZIP is that its single
archive file format specific. BUT, I have been using it
extensively for years now, use it for almost everything I do
archive file wise, am confident its not going to fang my bum.

It seems to me its better to put up with the irritation of
it only handling one archive format than to change and pray.

PE> I use it on my system,

That doesnt make much difference from my point of view, since
getting PKUNZIP to report archive file errors atleast provides
an ongoing check on that bit.

PE> and you may find it a preferable way to unzip your archives.

PE> That then transfers the problem to getting pktjoin to display
PE> error messages.

I think you have missed the point here rather. You MUST check that
the unarchiver, whatever it is, has actually unarchived the PKTs
successfully without losing any, say because there wasnt enough
free space. There is no other viable approach to that bit of the
total op. The absolutely LAST thing that should ever be done is
to carry on regardless, ignore all error messages, coz that will
normally mean that a whole fucking chunk of mail has been silently
filed in the bin. If the incoming PKTs have just one big PKT in them,
you will likely notice the dearth of mail, but if you have say two
reasonably large ones, you may well NOT notice you only got half.

And that is precisely what happened on the day it fanged my arse.

PE> But you can probably use Paul Markham's PKT sorter to do
PE> that for you, as it's got far more code in it than PKTJOIN,
PE> and probably does full error checking.

Thats not actually the bit I was gnashing my teeth about. Its not
that hard to do an overall check outside PKTJOIN, the obvious thing
to do is to have a completely separate process which just counts the
messages in the original PKTs, and compares that with how many end
up in the QWK. Then you have a good overall check of everything
thats happened between those two ends of the process.

In fact even just comparing the total size of the created QWK with
the total size of the original PKTs and checking that its higher is
a check for gross mail loss.

PE> That then transfers the problem to PKT2QWK.

Yeah, thats why an overall comparison of message numbers going in,
and message numbers coming out the other end is the best approach.

PE> But Bob is writing a replacement for that,

And you seriously think that the way to get a reliable mail system
is to rely on what a learner is producing as he learns ?  Yeah right |-)

PE> which will have full error checking and no bugs. That completes
PE> the cycle.

Trouble is that the dog shit between his ears will inevitably
contaminate the code |-)

--- PQWK202