Date: Mon, 15.02.21 12:04
2021 FTSC Standing Member Election -
Nick wrote (2021-02-12):
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
/* 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.
* Origin: . (2:280/464.47)