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

 RS> Thats only true if you count PKT messages in the PKT>QWK code.

  Why do you suspect the unreliability of the code? Jeeze - it's
simple enough!

 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.

  Yes. I agree. You need to look at the archived pkt before it's
unzipped, and at the qwk archive after it's zipped. Wouldn't a size
check be good enough? 

 RS> I actually meant using the size data thats in the archive file
 RS> embedded directory.

  I wrote a VB program that does that, for an unzipper I was making,
but it's pretty messy... and slow.

 RS> You really should be doing the calculation on the unarchived
 RS> size, not the archived size, coz the packing ratios vary quite
 RS> a bit between PKT and QWK since the common strings are
 RS> different.

  Yair... but you tend to get a consistent average over various
packets and sizes. Oddly, the QWK ends up a bit smaller, even with the
extra .ndx files and control.dat. It's a real drag reading the archive
header for file sizes, and they're all different. It wouldn't be too
bad for just zip, say.

 BL> All I want to do, is print a warning message, abort the
 BL> conversion, and save the original packets.

 RS> Thats a problem in some ways. There is a lot to be said for
 RS> trying to carry on regardless if a fixup does appear to have
 RS> got back into synch, notify the user and certainly keep the
 RS> originals.

  Well... the only reason it'll stuff up is if the packet is damaged
by the time the converter gets it... or if it runs out of memory .

 BL> You'd have to find the faulty packet yourself.

 RS> Well, I think it should give you its name, particularly if its
 RS> processing PKTs individually. In other words if its not using
 RS> an external PKT join first.

  That's a good idea! Christ knows how I'll do it, but I process them
one at a time as you say, so it should be possible to print that name
as part of the error routine. That's a really good feature.

 RS> Fact remains tho, for a reliable safety check message counter
 RS> in PKTs, you need a completely different alg, new code, the
 RS> works. I'm not convinced its particularly difficult.

  That won't help. It'd work if I read the files in the archive, but
if I have to unzip them and open them, it'll end up the same as the
converter, but less robust. You can't look for any single thing that
defines a message unambiguously, you have ot read it step-by-step. The
pkt format is mad! You can't even find anything to double-check a
message if you miss a null terminator. QWK has a possible double check
with the ndx files, but with pkt there's nothing.

  IMO, the header ought to be a fixed length with spaces for padding.
That way, you coud do it two ways.

 RS> Assuming various things like the code which purports to be
 RS> doing that really is doing that at all times.

 BL> and if there is no error, it *has* to write an equivalent QWK
 BL> message.

 RS> Software aint like that Bob |-)

  This simple stuff is. Writing code is very like designing a circuit;
you stuff around until you find code that *wants* to work because it
can't do anything else. Bugs are mostly oversights, not errors in the
computer itself. With more complex code, I would concede your point.

Regards,
Bob




___ Blue Wave/QWK v2.12
@EOT:

---