KR> my mail last thursday was .th2, followed on friday by .th3. dunno
KR> what happened to .th0 and .th1. i certainly didn't do any previous
KR> connects, and the .th2 was a normal size for a daily packet.

PE> Ok, what happened was that on the 19/5, your system rejected
PE> 0000fffa.th1, which I tried to send you.  This took it out of
PE> my .HLO file, but left the th1 file sitting there.  Indeed, the
PE> TH1 file is still sitting there doing nothing, and won't be sent
PE> to you because it's not in the HLO file, and whenever squish needs
PE> to create a new archive, it sees the TH1 sitting there and creates
PE> a TH2 and then adds the TH2 to the .HLO file.

KR> sounds a great theory paul, but what happened to .th0?

RS> Presumably it had been successfully sent the day before the attempt
RS> to send the .TH1 failed.

KR> since the day before was wednesday, that would have been a major brain
KR> fart, and since .we1 was received on the same mail run as .th2 it seems
KR> exceedingly unlikely.

We are getting tangled in the days and weeks. You saw the TH2 on a
thursday. It was the PREVIOUS FRIDAY that your system had refused
a TH1. The TH0 had been sent successfully the day before your system
had refused the TH1. The next week, the refused TH1 was still there,
so no TH0 or TH1 was made, a TH2 and TH3 were made instead, due to
the presence of the refused TH1 still on Pauls system.

KR> exactly the same thing happened this thursday, and i was watching
KR> this time. nothing funny happened, just the receipt of .we1, then
KR> .th2. next day .th3 arrived as before.

RS> Thats just the old refused .TH1 still there on Pauls causing that.

KR> so paul has already said,

That repeated skipping of .TH1 is very clearly whats going on.

KR> but, if there is a refused packet sitting there on tml, why aren't i
KR> missing any mail,
KR> and why was ,th2 the normal size for a daily mail packet?

Because by the time a .TH2 was made, there was already a refused
.TH1 on Pauls system, which prevented that name being used. So
all the mail that would otherwise have gone into a .TH1 goes
into a .TH2 instead. So nothing is missing if you get the .TH2.

I'm not convinced its possible to say whats 'normal size'
anyway, it swings around quite a bit size wise, even if
you religiously always call at the same time every day.

KR> unfortunately the bink log gets overwritten each day, but
KR> i will save it in future. i see no reason that, after 12 months
KR> with no changes, bink would suddenly start to refuse mail.

RS> Sure, but then computings like that. When you do eventually
RS> find out why it has suddenly started to do something different,
RS> you usually can see why it did.

KR> yes rod, in the 25 years that i've been making a living
KR> out of computers, i have come across such things.

So your last sentence above that I commented on is just plain
wrong, there is a perfectly good reason, even if you cant see it.

KR> it is indeed possible that bink 2.56 has such a bug,

It doesnt have to be a Bink bug, with your reconfiguration of
your system THATS actually a much more likely reason. Particularly
when presumably the presence of a .TH1 on your system when you did
the mail run is why Binkley refused a new one. It wouldnt be that
surprising if that reconfig had managed to have one there that would
not otherwise have been there.

KR> although, given that it has been out now for 2.5 years
KR> or so, it is relatively unlikely to have gone unreported.

I dont think a bug is the mostly likely reason, FAR more
likely its your reconfig.

KR> i may get tempted to use paul's fudged version of bink as then
KR> i could blame him no matter what happens, but i am reluctant to
KR> give up a stable reliable product for a potential can of worms.

Sure, no one is suggesting you should, just pointing out that your
'nothings changed in 12 months' is just plain wrong about your machine
and that its hardly that shocking if you see some effect of the reconfig.

KR> the system here is being rebuilt from end to
KR> end to integrate the new 2.1 gig 7200rpm drive,

RS> Funny that, and you are surprised it does something
RS> different to what it has been doing for the last 12 months ?

KR> yep.

Nuts.

Particularly when no one else is reporting Pauls starting to do
that to them too, its more than a tad unlikely its at Pauls end,
when you have just done a 'rebuilt from end to end' yourself.

RS> Thats absolutely classic, if things start to be seen to be
RS> different, and you have just changed your system, very very
RS> likely indeed its not a coincidence. Tho sometimes it is anyway.

KR> having two bob each way here?

Nope, nothing remotely like it. You have reconfigured your system
'end to end', you have seen a blemish. You are surprised. You shouldnt be.

KR> a singular event some two weeks after
KR> the change seems unlikely to be related,

Well, the effect of a .TH1 will only be seen once a week anyway, coz
its only once a week that Pauls will even try to send you one. And it
would be very desirable to work out just when the .TH1 was actually
first refused compared with that reconfig. Because if it was refused
on the first day Pauls tried to send you it after the reconfig, and
you never noticed anything that day, and the TH2 appeared the NEXT
week on that day, that would explain the 2 week effect.

KR> especially since the entire directory structure was
KR> simply copied to another partition, and then back with
KR> the only difference being that it is now on a c: partition
KR> of 320 megs instead of a c: partition of 160megs.

Thats what you thought you had done successfully. It wouldnt
actually be the first time in recorded history that what actually
did get done was just a little different to what you thought
happened. And if that happened to involve a .TH1, that would
explain why your Bink refused the offer of a new one from Pauls.

KR> but the only thing that has happened to the point
KR> is to copy it to another partition, and then back
KR> to it's own, it is even on the same physical drive.

RS> Heard it all before Keith. Time will tell what its due to, but I wont be
RS> exactly shocked speechless if it does turn out to be due to your reconfig.

KR> we'll see, but with 11 mail runs since and no re-occurrence
KR> the probability of it being a singular event rises every day,

Thats all completely irrelevant if your reconfig just managed somehow
to get a single .TH1 in the inbound directory which caused your Bink

(Continued to next message)

--- PQWK202