KR> perhaps you should fix your dinosaur technology so that dupes are
KR> checked for before the transfer just like the city. the order of the

PE> ROFL.  You've pointed off the city before have you, and he managed
PE> to set up Binkley to avoid dupes.  Amazing stuff this guy at the
PE> city.  Corse there's always the chance that you're getting confused
PE> between BBS and mailer technology.  If you download MINPOS2 or whatever
PE> it's called now, you might be a bit more familiar with it.

KR> nope afaik city doesn't do points. his message system is not what the

IOW he has exactly the same technology that I do.  If a sysop
crashes a file to him that he already has, he doesn't have any
protection against it.

KR> is a dupe the xfer aborts. if you don't have the brains to work it out
KR> for yourself, i suggest that you could ring john and ask him to explain

Explain how to stop points from sending dupes?

KR> it to you. i think that the first suggestion would be not to use
KR> binkley, 

So what's he got that does FTS-1 and FTS-4 under OS/2 32-bit and
doesn't cost me anything and comes with source? 

KR> but then, as you have the source code of bink, it shouldn't be
KR> too hard for you to change it should it?

I can give you the source code in about 3 minutes.  If it's not too
hard to change (your assertion) then please FREQ BTPE302.ZIP and 
send me the diffs so that I can apply them to BTPE303.ZIP.  Thanks
for your cooperation.

KR> files was never specified by you, so it seemed logical to send the tic
KR> first, there is no problem in reversing it - all you needed to do is
KR> ask.

PE> I didn't know before, but I do now.  I was quite surprised to see
PE> the *.BAD in my inbound.  BFN.  Paul.

KR> would putting the .tic file after the main file actually stop the sytem
KR> from accepting it?

It would have been accepted into SPECIALR.  It's only the fact that
transfer aborted that screwed it up, because it had the TIC file
but no real file, so decided it was bad.  BFN.  Paul.
@EOT:

---