BL> Your pkt2qwk compares the size of the PKT to the QWK, and I
 BL> rather like that. I could check the ratio, and if I lose 10%
 BL> (say), I could add a warning and not erase anything until the
 BL> user says so.

 RS> Trouble with the way its done now is that it assumes that the
 RS> combined PKT really is the total of the PKT mail which was in
 RS> the archived PKTs. There is no guarantee that it is.

  It's a pretty silly check, really, they way it's done in sequence.
Each PKT message writes a QWK message, and the totals are going to be
about the same anyway, even with errors.

 RS> If you are going to do that sort of check it would be much
 RS> better to look at the saved archived PKTs with an archiver etc
 RS> to get the total size of the PKTs in there from the directory
 RS> info in the archive and compare that with the resulting QWK.

  I agree, but it's a problem under VB, that doesn't want to know
about the size of unopened files. I suppose I could open then first,
and read the length... I'll give it a go.

 RS> Trouble with the size comparison tho is that it cant hope to
 RS> pick up more than gross problems, wont catch say a single
 RS> message lost for some problem with the message boundary
 RS> detection etc.

  I was trying to work out a way to double-check message ends and
begins, but in the end I decided to let it go. If it misses a field,
it soon stuffs up in a big way, and the error routine finds it. All I
want to do, is print a warning message, abort the conversion, and save
the original packets.

  What I've done is safe, but a bit of a nuisance. I save the original
archived packets to a "sv" directory, and remove them from the input
"rx" directory so the program won't run a second time until you copy
from the sv back to the rx. You'd have to find the faulty packet
yourself.

 RS> Nope, you missed my point. You want a completely separate
 RS> standalone ute which counts the messages in the PKTs, ideally
 RS> with a completely separate algorithm too. Then the comparison
 RS> of what it counts with what your PKT2QWK converter counts in
 RS> the QWK produced really is useful. 

 RS> The counting ute isnt hard, pretty trivial compared to the
 RS> converter.

  Actually, the counting ute would be nearly the same as the
converter. I was able to combine pktjoin with no overhead at all.

  PKT format has a 58-byte packet header you ignore, and a 14-byte
message header you also ignore, because there are nulls in there. Then
you count nulls to find the fields and finally the message terminator.
The converter does this anyway, but adds processing that actually
reads the fields, reformats them, relates them to the nulls, and
identifies the message that it writes into the QWK. If you skip a 
null or find an extra one, it soon stuffs up and grinds to a halt. 
A simple counter would be less robust than the converter itself.

  You could test the input packets by counting nulls and dividing by
five, but the converter does this anyway, and more, and if there is
no error, it *has* to write an equivalent QWK message. I think I'll 
try reading the size of the PKT archives and comparing them to the 
QWK, as you say.

...[later]

  Well, that was easy. The QWK seems to be about 7% smaller than the 
sum of the packets. I'll set the limits at 0% and 15%... plenty to 
find a dropped packet if UNZIP buggers it.

Regards,
Bob


      
___ Blue Wave/QWK v2.12
@EOT:

---