PE>> There are many things that can go wrong (ask Dieter).  If you save
 PE>> your inbound packets, you can always go through the steps again,
 PE>> you can derive the QWK, I can debug problems, etc etc.  I can't
 PE>> see any harm in doing it, it's only 300k or whatever you need to
 PE>> keep.  You can delete it before your next poll.

 FM> I agree, and will do so. I just hadn't thought I'd need to, and the
 FM> TinyPoint batch files didn't.

Dieter, can you fix that too!

 FM> incorrectly into MESSAGES. BTW, what is the structure of an index entry?
 FM> It seems to me to be a flag word (always 0x0000 or 0x8000), an index
 FM> byte into MESSAGES in 192-byte blocks, a flag byte (0x8?) and the area
 FM> number as a byte. Can you give me the structure?
 
I can't remember.  You can FREQ the QWK specs and the source to
PQWK and that will give you everything you should need.  BTW,
PVERT may be pretty badly written, but it is the best public
domain one around (except for PQWK which is derived from it),
so unless someone writes a replacement, there's not much you
can do about it.  Personally I would have written it so that
it worked on AmigaDos too, instead of lame-brained-C-programmer
style that Mark and most of the rest of the world uses.

 PE> FM>> Doesn't matter, it's not the problem. Try it for yourself with
 PE> FM>> fucked.zip. Unzip it, delete the indexes, run QWK2PKT
then PKT2QWK.
 PE> FM>> A new set of indexes which are fucked.

 PE>> Nope, a perfectly working set.  I did use PQWK 2.21 not 2.20, but

 FM> Yeah, I get a perfectly working set from doing that on FUCKED.ZIP, too.
 FM> That other behaviour was what I observed on an earlier problem packet,
 FM> which I didn't save.
 
What's the point in sending me test data that demonstrates the
problem if it doesn't even demonstrate it for you?!  Dieter did
exactly the same thing a couple of months ago. 

 PE>> the changes I made were only to do with netmail addressing, not
 PE>> indexes.  I'll let you into a secret.  Once the thing is a single
 PE>> PKT file, it's as clean as it can be, just like the original PKTs

 FM> It's a slightly different size, though, I think.
 
Sure, it should be smaller because the header and trailer on each
packet only appear once in the combined one.  Still a clean packet
though, despite the best efforts of Rod running around in ever
decreasing circles about the world caving in. 

 FM> I think the PKTJOIN problem is important, I'm sure you would regard it
 FM> as a bug if PKZIP SUMFIN *.* ended up including part of the zip file
 FM> being created within itself, in some circumstances. Phil Katz checks for
 
Nope, when I first started using archivers I thought to myself "I
wonder if it can do this".  I do like the fact that it does, but
that's another issue. 
 
 FM> the output file in the DOS FindNext loop, I think PKTJOIN should too.
 
What about the way DOS automatically converts the filename specified
into uppercase.  I would have to do a case-insenstive search to handle
that.  What about in DOS it automatically truncates the name under
certain circumstances.  I very rarely put any code in that is in any
way machine-dependant.  I write all my programs as if I'm writing on
a machine defined by ISO/IEC 9899-1990.  I can't see the machine yet,
but I've learnt all about it.  Of course, I simultaneously release
the source code as well, so if you really wanted to change it you
can.

That's another thing I'd like to set up.  What I would like is for
other people to be able to access my wealth of compilers, by 
uploading a file etc, and it automatically gets compiled and linked
and sent back to them on their next poll.  Wouldn't that be good?
I wonder what other things besides compiles could be done that way?
I think UUCP does something similar.

 FM> As for the current problem, well that depends on whether I'm doing
 FM> something which is screwing things up which we don't know yet. However,
 FM> *I* think the spec for PKT2QWK should be to create a valid MESSAGES.DAT,
 FM> with valid indexes pointing to it. As you say, you don't know why the
 FM> existing version doesn't do that.
 
It does.  Preconditions are that you have a valid PKT file and no
*.NDX files lying around and you have sufficient disk space and
memory.  BFN.  Paul.
@EOT:

--- Mksmsg