A few weeks ago I noticed Binkd started spitting up errors messages saying that
the binkd.conf has changed! Reloading configuration...
I got the latest from http://www.filegate.net/ipfn/i-binkd/BINKD.TXT and yest binkd still says same error messages over and over again. What do I do to fix this? Does it even need fixing?
--- SBBSecho 2.27-Win32
* Origin: Time Portal - timeport.synchro.net:2112 1:322/764 (1:322/764)

*** Answering a msg posted in area BAD_MSGS.

Hi,

On 2002-01-17 11:30:00, James Barrett wrote to All:
^^^^^^^^^^^^^^^^^^^
about: "binkd.conf has changed??":

A few weeks ago I noticed Binkd started spitting up errors messages
saying
that the binkd.conf has changed! Reloading configuration... I got the latest from http://www.filegate.net/ipfn/i-binkd/BINKD.TXT and yest binkd still says same error messages over and over again. What do I do to fix this? Does it even need fixing?

It might have something to do with your system clock not working properly!?

Bye, Wilfred.


--- FMail-W32 1.69.22.178-B20160706
* Origin: Native IPv6 connectable node (2:280/464)

On 08/03/16, James Barrett said the following...

A few weeks ago I noticed Binkd started spitting up errors messages
saying that the binkd.conf has changed! Reloading configuration...
I got the latest from http://www.filegate.net/ipfn/i-binkd/BINKD.TXT and yest binkd still says same error messages over and over again. What do I do to fix this? Does it even need fixing?

If binkd is started with the -C switch it will reload the configuration and
say so in the log and on the screen. It should only happen if you change you binkd.conf.

Has your bink.conf changed?

Ttyl :-),
Al

--- Mystic BBS v1.12 A30 (Linux)
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

03 Aug 16 12:08, you wrote to James Barrett:

A few weeks ago I noticed Binkd started spitting up errors messages
saying that the binkd.conf has changed! Reloading configuration... I
got the latest from http://www.filegate.net/ipfn/i-binkd/BINKD.TXT
and yest binkd still says same error messages over and over again.
What do I do to fix this? Does it even need fixing?

If binkd is started with the -C switch it will reload the
configuration and say so in the log and on the screen. It should only happen if you change you binkd.conf.

Has your bink.conf changed?

that was a regurge from Jan 2002 ;)

apparently there's a system in your feed line that is ""fixing"" what it considers to be "too old" or "invalid" dates...

)\/(ark

Always Mount a Scratch Monkey

... Earth is 98% full. Please delete anyone you can.
---
* Origin: (1:3634/12.73)

On 08/03/16, mark lewis said the following...

that was a regurge from Jan 2002 ;)

Really!? It arrived here with todays date and a time of 10:08 this morning.

apparently there's a system in your feed line that is ""fixing"" what it considers to be "too old" or "invalid" dates...

That may be. I have a different feed line here than fidotest.

Ttyl :-),
Al

--- Mystic BBS v1.12 A31 (Linux)
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

03 Aug 16 16:38, you wrote to me:

that was a regurge from Jan 2002 ;)

Really!? It arrived here with todays date and a time of 10:08 this

morning.

yeah... it arrived here with the original date and wilfred saw it, too...

[quote=wilfred]
On 2002-01-17 11:30:00, James Barrett wrote to All:
^^^^^^^^^^^^^^^^^^^
about: "binkd.conf has changed??":
[/quote]

apparently there's a system in your feed line that is ""fixing"" what
it considers to be "too old" or "invalid" dates...

That may be. I have a different feed line here than fidotest.

that's the only real way i know of for messages' dates to be changed... the tool is known as PKTDATE...


y2ktool5.zip 370k 01-14-00 Fido Year 2000 Tools Rel. 5 by Tobias Ernst
===========================================
PKTDATE 1.4 is a program that can analyse
PKT files for structural errors that result
from year 2000 related bugs in the creating
software and automatically fix such broken
PKT files. It is intended for use at hub
level in the Fidonet distribution structure
in order to alleviate the effects of the
year 2000 problem on the smooth operation
of Fidonet. Also included are a general
information text on the year 2000 problem
in Fidonet, and tools for analysing MSG,
JAM and Squish message base files.
Includes OS/2, Win32, DOS, Linux and Amiga
binaries and source. Unzip with -d option!
= Jetzt auch mit Deutscher Dokumentation! =


there may be a newer version available, though... my main system uses it but i do not have it fix the dates any more... only report...

)\/(ark

Always Mount a Scratch Monkey

... If it is to be, it is up to me! (10 most important 2 letter words)
---
* Origin: (1:3634/12.73)

Hi mark,

On 03 Aug 16 17:18, mark lewis wrote to Alan Ianson:
about: "binkd.conf has changed??":

that was a regurge from Jan 2002 ;)

James Barrett has only been 322/764 since november last year. So I think his system date is wrong.

apparently there's a system in your feed line that is ""fixing"" what
it considers to be "too old" or "invalid" dates...

It shouldn't do that! ;)

I got James message 3 times. Only one had a current date, and the following path lines:

PATH: 322/764 759 123/500 140/1 5020/1042 280/5555

The other two with the old date had these paths:

PATH: 322/764 759 123/500 154/10
PATH: 322/764 759 123/500 261/38 249/303

So one of these three systems must be changing the date:

140/1 5020/1042 280/5555

Afaik 280/5555 isn't doing that. So 140/1 and 5020/1042 remain...

Wilfred.

--- FMail-W32 1.69.21.177-B20160330
* Origin: point@work (2:280/464.112)

Hi mark,

On 03 Aug 16 20:22, mark lewis wrote to Alan Ianson:
about: "binkd.conf has changed??":

there may be a newer version available, though... my main system uses
it but i do not have it fix the dates any more... only report...

I think that's the correct thing to do. If you change the message date on messages, that just confuses matters. And the massive regurgitations caused by rescans we sometimes see, can't be stopped by filtering old messages, if that happens...

Wilfred.

--- FMail-W32 1.69.21.177-B20160330
* Origin: point@work (2:280/464.112)

04 Aug 16 09:33, you wrote to me:

there may be a newer version available, though... my main system uses
it but i do not have it fix the dates any more... only report...

I think that's the correct thing to do.

it depends on the situation, really... now that we're 15+ years after y2k, sure, report only... within y2k+3 maybe? fixing bad dates was the more proper thing to do so that posts were not lost because some system thought it was too old...

If you change the message date on messages, that just confuses
matters. And the massive regurgitations caused by rescans we sometimes see, can't be stopped by filtering old messages, if that happens...

regurges shouldn't be able to happen anyway... too many cooks spoil the stew and with so many wanting to do things their way because they don't know how it should be done, well, every tosser has its own way to know what the last message scanned out was... that's what leads to regurges when folks change software...

)\/(ark

Always Mount a Scratch Monkey

... Bullsh#t! Pain is just weakness leaving the body. Gaius Marius, 105BCE. ---
* Origin: (1:3634/12.73)

Hello Wilfred,

Thursday August 04 2016, Wilfred van Velzen wrote to mark lewis:

that was a regurge from Jan 2002 ;)

James Barrett has only been 322/764 since november last year. So I
think his system date is wrong.

apparently there's a system in your feed line that is ""fixing""
what it considers to be "too old" or "invalid" dates...

It shouldn't do that! ;)

I got James message 3 times. Only one had a current date, and the following path lines:

PATH: 322/764 759 123/500 140/1 5020/1042 280/5555

The other two with the old date had these paths:

PATH: 322/764 759 123/500 154/10
PATH: 322/764 759 123/500 261/38 249/303

So one of these three systems must be changing the date:

140/1 5020/1042 280/5555

Afaik 280/5555 isn't doing that. So 140/1 and 5020/1042 remain...

My system definitely does not do such things.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20151128
* Origin: Moscow, Russia (2:5020/1042)

Hi,

On 2016-08-04 19:02:14, Michael Dukelsky wrote to Wilfred van Velzen:
about: "binkd.conf has changed??":

apparently there's a system in your feed line that is ""fixing""
what it considers to be "too old" or "invalid" dates...

It shouldn't do that! ;)

I got James message 3 times. Only one had a current date, and the
following path lines:

PATH: 322/764 759 123/500 140/1 5020/1042 280/5555

The other two with the old date had these paths:

PATH: 322/764 759 123/500 154/10
PATH: 322/764 759 123/500 261/38 249/303

So one of these three systems must be changing the date:

140/1 5020/1042 280/5555

Afaik 280/5555 isn't doing that. So 140/1 and 5020/1042 remain...

My system definitely does not do such things.

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify this?

Bye, Wilfred.


--- FMail-W32 1.69.22.178-B20160706
* Origin: Native IPv6 connectable node (2:280/464)

Hello Wilfred,

Thursday August 04 2016, Wilfred van Velzen wrote to Michael Dukelsky:

apparently there's a system in your feed line that is
""fixing"" what it considers to be "too old" or "invalid"
dates...

It shouldn't do that! ;)

I got James message 3 times. Only one had a current date, and
the following path lines:

PATH: 322/764 759 123/500 140/1 5020/1042 280/5555

The other two with the old date had these paths:

PATH: 322/764 759 123/500 154/10
PATH: 322/764 759 123/500 261/38 249/303

So one of these three systems must be changing the date:

140/1 5020/1042 280/5555

Afaik 280/5555 isn't doing that. So 140/1 and 5020/1042
remain...

My system definitely does not do such things.

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify this?

Yes, I store all incoming packets for several days. The message with MSGID: 414.fido-binkd@1:322/764 00ac33a7 that came to me from 1:140/1 had time 03 Aug 16 10:08:29.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20151128
* Origin: Moscow, Russia (2:5020/1042)

04 Aug 16 21:06, Michael Dukelsky wrote to Wilfred van Velzen:

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify this?

Yes, I store all incoming packets for several days. The message with

MSGID:

414.fido-binkd@1:322/764 00ac33a7 that came to me from 1:140/1 had time 03 Aug 16 10:08:29.

Yes, I have the same time stamp here. Not the .pkt but tossed to msgbase from 1:140/1

PATH: 322/764 759 123/500 140/1

'Tommi

---
* Origin: =========================================== (2:221/0)

Hello Tommi,

Thursday August 04 2016, Tommi Koivula wrote to Michael Dukelsky:

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify
this?

Yes, I store all incoming packets for several days. The message
with MSGID: 414.fido-binkd@1:322/764 00ac33a7 that came to me
from 1:140/1 had time 03 Aug 16 10:08:29.

Yes, I have the same time stamp here. Not the .pkt but tossed to
msgbase from 1:140/1

PATH: 322/764 759 123/500 140/1

I have unsubscribed this echo from 1:140/1.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20151128
* Origin: Moscow, Russia (2:5020/1042)

Hi,

On 2016-08-04 21:06:10, Michael Dukelsky wrote to Wilfred van Velzen:
about: "binkd.conf has changed??":

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify this?

Yes, I store all incoming packets for several days. The message with

MSGID:

414.fido-binkd@1:322/764 00ac33a7 that came to me from 1:140/1 had time 03 Aug 16 10:08:29.

Ok, than it's clear where the date change occurred.

Bye, Wilfred.


--- FMail-W32 1.69.22.178-B20160706
* Origin: Native IPv6 connectable node (2:280/464)

Hi,

On 2016-08-04 22:16:44, Michael Dukelsky wrote to Tommi Koivula:
about: "binkd.conf has changed??":

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify
this?

Yes, I store all incoming packets for several days. The message
with MSGID: 414.fido-binkd@1:322/764 00ac33a7 that came to me
from 1:140/1 had time 03 Aug 16 10:08:29.

Yes, I have the same time stamp here. Not the .pkt but tossed to
msgbase from 1:140/1

PATH: 322/764 759 123/500 140/1

I have unsubscribed this echo from 1:140/1.

Why just this area? If he's changing dates, he probably does that on all echomail (with old dates) in every area...

Bye, Wilfred.


--- FMail-W32 1.69.22.178-B20160706
* Origin: Native IPv6 connectable node (2:280/464)

04 Aug 16 22:19, you wrote to Michael Dukelsky:

PATH: 322/764 759 123/500 140/1

I have unsubscribed this echo from 1:140/1.

Why just this area? If he's changing dates, he probably does that on
all echomail (with old dates) in every area...

every area he carries in that feed... he easily has more than one feed (eg: areas he carries that are not on the NAB) that he provides...

)\/(ark

Always Mount a Scratch Monkey

... 18 out of 10 schizophrenics agree.
---
* Origin: (1:3634/12.73)

Hello Wilfred,

Thursday August 04 2016, Wilfred van Velzen wrote to Michael Dukelsky:

Than 140/1 remains as the cause, which is Bob Seaborn.

If you have a backup of incomming .pkt files you could verify
this?

Yes, I store all incoming packets for several days. The message
with MSGID: 414.fido-binkd@1:322/764 00ac33a7 that came to me
from 1:140/1 had time 03 Aug 16 10:08:29.

Yes, I have the same time stamp here. Not the .pkt but tossed to
msgbase from 1:140/1

PATH: 322/764 759 123/500 140/1

I have unsubscribed this echo from 1:140/1.

Why just this area?

Where do you see that _just_ this area? :)

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20151128
* Origin: Moscow, Russia (2:5020/1042)

03 Aug 16 12:08, you wrote to James Barrett:

A few weeks ago I noticed Binkd started spitting up errors messages
saying that the binkd.conf has changed! Reloading configuration... I JB>> got the latest from http://www.filegate.net/ipfn/i-binkd/BINKD.TXT
and yest binkd still says same error messages over and over again.
What do I do to fix this? Does it even need fixing?

If binkd is started with the -C switch it will reload the
configuration and say so in the log and on the screen. It should only happen if you change you binkd.conf.

Has your bink.conf changed?

that was a regurge from Jan 2002 ;)

apparently there's a system in your feed line that is ""fixing"" what it >considers to be "too old" or "invalid" dates...

)\/(ark

Ugh... I didn't even notice that the date was wrong. Looks like I need to change the battery.
--- SBBSecho 2.27-Win32
* Origin: Time Portal - timeport.synchro.net:2112 1:322/764 (1:322/764)