NA> ... Kindof like what you were told recently by the Husky guys.
How is that different than your comment about semaphores in BINKD?
NA> I asked for the same thing over the years. I'm wondering why the NA> arrogance insist that we kill things by Pid instead of telling NA> the program to exit gracefully.
You could have easily fixed it yourself. But did it matter? In the end digital man discovered and fixed a simple bug. Everybody's happy.
At the moment andrew clarke is doing excellent work in opening a can of worms that leads back to the Squish MsgAPI. For me it all started when Wilfred and mark lewis told me about problems with Squish and dupes in the MUFFIN echo.
Subject: Squish on Linux (compile errors) Date: 21 Nov 2019 20:44:25 +0100 MSGID: 2:280/464 5dd6ea30 WvL> There's also the problem that the squish message base stores date/time WvL> stamps with a resolution of 2 seconds. That has been causing problems in WvL> the past where a squish system forwarded messages to its other links with WvL> the date/times changed from the original, and so causing undetected dupes WvL> on some systems.
Date: 22 Nov 2019 19:19:14 -0500 MSGID: 1:3634/12.73 5dd87e2e ML> we specifically tracked ML> this modified time stamp problem down several years ago... every message ML> coming via squish had the seconds in multiples of two... no odd numbers ML> at all...
By reading the Squish Developer Kit documentation and some test that theory turned out to be wrong for the Squish tosser. There is also this remark in Squish's msgapi.h:
byte __ftsc_date[20]; /* Obsolete date information. If it weren't for the * * fact that FTSC standards say that one cannot * * modify an in-transit message, I'd be VERY * * tempted to axe this field entirely, and recreate * * an FTSC-compatible date field using * * the information in 'date_written' upon * * export. Nobody should use this field, except * * possibly for tossers and scanners. All others * * should use one of the two binary datestamps, * * above. */
But I also didn't believe that Wilfred and mark just invented a problem that never existed. Maybe another tosser that supports Squish message bases? Husky's hpt was the most obvious first candidate to look at. Tests with pass-through / one-pass tossing didn't show any problems. But later I could reproduce the problem by rescanning mails from a Squish message base ("%RESCAN AREA"). The newest finding is that hpt also modifies the time stamp for rescanned mails from a JAM message base.
If you think this is all motivated by an urge to troll people, you really should check your definition of trolling. But I doubt you care. You're throwing shit at the wall until something sticks.
