Fidonet Portal

From: Oli (2:280/464.47)
To: All
Date: Mon, 15.02.21 12:04
2021 FTSC Standing Member Election -
.... continuance

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
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.

* Origin: . (2:280/464.47)


This forum contains echomail areas hosted on Nightmare BBS You can browse local echomail areas, italian fidonet areas and a selection of international fidonet areas, reading messages posted by users in Nightmare BBS or even other BBSs all over the world. You can find file areas too (functional to fidonet technology). You can browse echomail areas and download files with no registration, but if you want to write messages in echomail areas, or use fidonet netmail (private messages with fidomet technology), you have to register. Only a minimal set of data is required, functional to echomail and netmail usage (name, password, email); a registration and login with facebook is provided too, to allow easy registration. If you won't follow rules (each echomail areas has its own, regularly posted in the echomail), your account may be suspended;