FM> Sure, no indexes or anything else in the directory when PKT2QWK
FM> goes to work. Nothing except the input PKT (from PKTJOIN).

PE> Actually, I think you were using old *.NDX files with new *.DAT.

Thats unlikely coz the worst that should do is just produce funny
looking messages as the index points to the wrong place in the DAT

PE> It's hard to tell, since it works fine here.  I need the original
PE> PKTs to do anything of substance.

I have kept some antiques which showed the problem. I havent been
energetic enough to have a close look at the problem, mainly coz
the created PKT out of PKTJOIN looks ok. It clearly aint tho and
some automated comparison between the original PKTs and the new
combined PKT is needed to see just whats wrong with the PKT which
causes PKT2QWK to produce a fucked set of NDXs.

The main reason I havent got around to it is that the workaround is
so easy, just process each archived set of PKTs individually thru to
a QWK. I have never seen the effect in that case, only when more than
one archived set of PKTs are processed in one run. And I havent seen
the bug for many months anyway.

And in some ways it makes more sense to piss off PKTJOIN and use Daves
message sorter to combine the PKTs anyway.

FM>> I'll upload tenmin.qwk as fucked.zip, so you can try it for yourself.

PE>> I had a look, and that's what it looks like to me, failure to delete
PE>> the NDX files.  Don't ask me why PKT2QWK appends to the NDX files,
PE>> that's what PVERT did.

That gives a different symptom.

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

I've never tried that.

PE> Nope, a perfectly working set.

You dont know that, you arent trying to read the QWK with OLX.

PE> I did use PQWK 2.21 not 2.20, but the changes I made were only
PE> to do with netmail addressing, not indexes.

PE> I'll let you into a secret. Once the thing is a single PKT file,
PE> it's as clean as it can be, just like the original PKTs I sent you.

Nice theory Paul. That doesnt explain how processing just one archived
file of PKTs at a time makes the problem go away.

PE> If the PKTs look OK, which they do, then if PKT2QWK fails to make
PE> nice indexes, it should do that ALL the time.

Nope, many software bugs aint like that. The bug is often sensitive
to something. That something is missing, it isnt visible. Just what
that critical something is which causes a fucked single PKT is as yet
unclear, but it does happen.

PE> Since everyone else is using PKT2QWK and indexes quite happily,

Only two are using OLX.

PE> it means you are doing something unusual.

Nope. Lousy logic.

FM> As a temporary workaround I'm going to change the batch file to
FM> only zip the .DAT files, but I'd rather see the bug fixed (and
FM> the one in PKTJOIN), if only to protect other innocents in future.

PE> I've been fixing problems with PQWK (ni-PVERT) for the last year,
PE> as they are reported.  Since it's not my code (mostly), I don't
PE> like touching it unless it's pretty important.  Getting the user
PE> to delete their *.NDX files is something I think they should live
PE> with rather than me have to change the code.

OTOH the evidence points to it being a PKTJOIN problem, not in the
Kimes code. Corse until the actual bug is found its hard to be sure.
And quite a few QWK readers cant rebuild missing NDXs anyway. BlueWave
for one.

PE> There might actually be a reason why it is that way (I've no idea
PE> what that reason might be).

Unlikely, its got all the classic symptoms of a bug which is sensitive
to the input files.

PE> BTW, the "innocents" are meant to be using the pre-canned TinyPoint
PE> scripts!!!  Which although out-of-date now, Dieter is revamping.

And there aint much evidence that if that was used that it would
eliminate the problem. Currently it looks like the ONLY thing which
matters is the collection of PKTs which is processed in one run.

--- PQWK202