There is no TZUTC: kludge...
It seems that FMAIL is removing the kludge. I'm not joking. The
kludge is there in JAM base before 'fmail scan'.
@MSGID: 2:221/6.600 63affb9c
@TID: FMail-lnx64 2.1.0.18-B20170815
@TZUTC: 0200
@CHRS: UTF-8 4
This one has the kludge! So it's only happening in FIDOTEST?
But this one has no PID:, should it?
That is highly surprising! Are you sure nothing else touches it?
It never happens on my own system, so I can't debug what doesn't reproduce. But can you send me the piece of FMail log where this
happens?
Did you compile FMail yourself? Or did you use one of the precompiled ones?
Can you experiment with the 'Tearline' option. There is a setting that doesn't add the TID kludge.
@MSGID: 2:221/6.600 63affb9c
@TID: FMail-lnx64 2.1.0.18-B20170815
@TZUTC: 0200
@CHRS: UTF-8 4
* Forwarded from FIDOTEST by Tommi Koivula (2:221/6.600).
* Originally by: Tommi Koivula (2:221/6.600), 31 Dec 22 11:00.
* Originally to: Wilfred van Velzen.
On 31.12.2022 0:14, Wilfred van Velzen wrote:
There is no TZUTC: kludge...
It seems that FMAIL is removing the kludge. I'm not joking. The kludge is there in JAM base before 'fmail scan'.
A test message before scanning in Golded:
===
Subj : 123
@MSGID: 2:221/6.600 63aff95c
@PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
@CHRS: UTF-8 4
@TZUTC: 0200
123
===
A test message after scanning in Golded:
===
Subj : 123
@MSGID: 2:221/6.600 63aff95c
@PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
@TID: FMail-lnx64 2.1.0.18-B20170815
@CHRS: UTF-8 4
123
===
It seems that FMAIL is removing the kludge. I'm not joking. The
kludge is there in JAM base before 'fmail scan'.
FMail also changes the order of kludges when scanning.
===
MSGID: 2:221/6.600 63b001e0
PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
CHRS: CP437 2
TZUTC: 0200
===
TID: FMail-lnx64 2.1.0.18-B20
CHRS: CP437 2
PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
MSGID: 2:221/6.600 63b001e0
===
Can you experiment with the 'Tearline' option. There is a setting
that doesn't add the TID kludge.
I'd like to investigate your jam messagebase files for a test
area, from before and after the scan.
TZUTC seems to disappear from the messages written in
SmapiNNTPd. Not Golded.
So it seems, so there must be something different to what
SmapiNNTPd does in a jam messagebase compared to Golded.
This one has the kludge! So it's only happening in FIDOTEST?
But this one has no PID:, should it?
No, written in Golded. Tearline, no PID.
That is highly surprising! Are you sure nothing else touches it?
I'm sure. Only SmapiNNTPd, Golded and FMail.
TZUTC seems to disappear from the messages written in SmapiNNTPd. Not Golded.
It never happens on my own system, so I can't debug what doesn't
reproduce. But can you send me the piece of FMail log where this
happens?
I send you the log.
Did you compile FMail yourself? Or did you use one of the precompiled
ones?
The precompiled from your site.
Can you experiment with the 'Tearline' option. There is a setting
that doesn't add the TID kludge.
Sure.
@MSGID: 2:221/6.600 63b0141e
@REPLY: 2:280/464 63b00619
@PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
@TEST: HELLO WORLD!
@CHRS: CP437 2
@EID: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32).
Wilfred van Velzen wrote:
Can you experiment with the 'Tearline' option. There is a setting
that doesn't add the TID kludge.
No TID, but no TZUTC either. :(
I added a TEST kludge to smapinntpd. :)
'Tommi
--- FMail-lnx64 2.1.0.18-B20170815
* Origin: --- (2:221/6.600)
SEEN-BY: 103/705 124/5016 153/757 154/10 203/0 221/1 6 360 240/1120 5832 SEEN-BY: 280/464 5003 5555 292/854 8125 301/1 310/31 335/364 341/66 SEEN-BY: 341/234 396/45 423/81 120 633/280 712/848 770/1 4500/1
@PATH: 221/6 1 280/464
I'd like to investigate your jam messagebase files for a test
area, from before and after the scan.
Investigate your inbound. :)
TZUTC seems to disappear from the messages written in
SmapiNNTPd. Not Golded.
So it seems, so there must be something different to what
SmapiNNTPd does in a jam messagebase compared to Golded.
And the same SmapiNNTPd with HPT has no such a problem.
Isn't SmapiNNTPd part of the HPT suite?
Let's see how JamNNTPd behaves with FMail.
That would be interesting!
TZUTC seems to disappear from the messages written in
SmapiNNTPd. Not Golded.
So it seems, so there must be something different to what
SmapiNNTPd does in a jam messagebase compared to Golded.
And the same SmapiNNTPd with HPT has no such a problem.
Let's see how JamNNTPd behaves with FMail.
@MSGID: 2:221/6.0 63b024d6
@REPLY: 2:280/464 63b01c1e
@PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
@EID: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32).
@CHRS: CP437 2
@TZUTC: 0200
@TEST: HELLO WORLD!
@TID: hpt/lnx 1.9 2022-07-03
It seems that FMAIL is removing the kludge. I'm not joking. The
kludge is there in JAM base before 'fmail scan'.
FMail also changes the order of kludges when scanning.
===
MSGID: 2:221/6.600 63b001e0
PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
CHRS: CP437 2
TZUTC: 0200
===
TID: FMail-lnx64 2.1.0.18-B20
CHRS: CP437 2
PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
MSGID: 2:221/6.600 63b001e0
===
I'd like to investigate your jam messagebase files for a test area, from before and after the scan.
TZUTC seems to disappear from the messages written in
SmapiNNTPd. Not Golded.
So it seems, so there must be something different to what
SmapiNNTPd does in a jam messagebase compared to Golded.
And the same SmapiNNTPd with HPT has no such a problem.
Isn't SmapiNNTPd part of the HPT suite?
No, but it uses the same smapi library.
Let's see how JamNNTPd behaves with FMail.
That would be interesting!
No problems with Jamnntpd.
But I made some research with GoldED's JAM hexdumps. There are two ways to store the TZUTC in JAM.
02004 [ 4]: "0200" smapinntpd & gecho
02000 [ 11]: "TZUTC: 0200" jamnntpd & golded
Maybe there is the reason why FMail strips the TZUTC when exporting?
Hi Tommi,
On 2022-12-31 14:02:30, you wrote to me:
@MSGID: 2:221/6.0 63b024d6
@REPLY: 2:280/464 63b01c1e
@PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
@EID: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32).
@CHRS: CP437 2
@TZUTC: 0200
@TEST: HELLO WORLD!
@TID: hpt/lnx 1.9 2022-07-03
Btw: This one has the TZUTC: kludge!
Hi Tommi,
On 2022-12-31 11:15:06, I wrote to you:
It seems that FMAIL is removing the kludge. I'm not joking. The
kludge is there in JAM base before 'fmail scan'.
FMail also changes the order of kludges when scanning.
===
MSGID: 2:221/6.600 63b001e0
PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
CHRS: CP437 2
TZUTC: 0200
===
TID: FMail-lnx64 2.1.0.18-B20
CHRS: CP437 2
PID: SmapiNNTPd/Linux/IPv6 1.3 20221231
MSGID: 2:221/6.600 63b001e0
===
I'd like to investigate your jam messagebase files for a test area, from
before and after the scan.
I investigated the before and after jam message base you sent me. Except for
the Snt flag, FMail doesn't seem to touch the message. When I look at the messages with GoldED they are identical including the order of the kludges...
But I made some research with GoldED's JAM hexdumps. There are two
ways to store the TZUTC in JAM.
02004 [ 4]: "0200" smapinntpd & gecho
02000 [ 11]: "TZUTC: 0200" jamnntpd & golded
Maybe there is the reason why FMail strips the TZUTC when exporting?
That rings a bell. But I have to investigate...
Found it! That special jam subfield 2004 is ignored by FMail. Apparently it is hardly ever used by software. Because it was in FMail like this from the start, a few decades ago. Golded knows how to handle it when encountered,
but doesn't use it when creating new messages in the jambase...
It should be an easy fix, but it will have to wait until next year. ;-)
Fixed this year. :)
Before scanning:
02004 [ 4]: "0200"
After scanning:
02000 [ 11]: "TZUTC: 0200"
So FMail now 'converts' 2004 to 2000.
Not intentional, but I can see how that can happen, when it's written back to
the jam message base.
@MSGID: 2:221/6.600 63b317f4
@REPLY: 2:280/464 63b048bd
@PID: SmapiNNTPd/Linux/IPv6 1.3 20230101
@TID: FMail-lnx64 2.1.0.20-B20230102
@BBSID: MXO
@TZUTC: 0200
@CHRS: UTF-8 4
@EID: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1.
It should be an easy fix, but it will have to wait until next year. ;-)
Fixed this year. :)
--- FMail-lnx64 2.1.0.20-B20230102
I turned "Update text after Scan" to "Yes"
Before scanning:
02004 [ 4]: "0200"
After scanning:
02000 [ 11]: "TZUTC: 0200"
So FMail now 'converts' 2004 to 2000.
That's opposite what happens with GoldED and HPT. ;) GoldED enters 2000 and
HPT converts it to 2004.
02000 [ 11]: "TZUTC: 0200" GOLDED BEFORE HPT SCAN
02004 [ 4]: "0200" GOLDED AFTER HPT SCAN
I also checked my tossers what they do when tossing to JAM. Gecho, Fastecho
and HPT all put 2004 into JAM.
It would be easy to change, but I'm reluctant to change what worked
for decades. And both are correct, so it doesn't matter...
Before scanning:
02004 [ 4]: "0200"
After scanning:
02000 [ 11]: "TZUTC: 0200"
So FMail now 'converts' 2004 to 2000.
Not intentional, but I can see how that can happen, when it's written
back to the jam message base.
That's opposite what happens with GoldED and HPT. ;) GoldED enters 2000 and
HPT converts it to 2004.
02000 [ 11]: "TZUTC: 0200" GOLDED BEFORE HPT SCAN
02004 [ 4]: "0200" GOLDED AFTER HPT SCAN
I also checked my tossers what they do when tossing to JAM. Gecho, Fastecho
and HPT all put 2004 into JAM.
I was writing a small converter from fmail to smapinntpd and I noticed that areas.bbs and areas.gld are using a different directory
separator.
Not a big deal, but perhaps windows version should write "\" and linux version "/" to those export files. :)
grep fmail_help areas.*
areas.bbs:!\bbs\fmail\msgbase\jam\fmail_help FMAIL_HELP 2:221/6 areas.gld:AREADEF FMAIL_HELP "FMAIL_HELP" A Echo JAM /bbs/fmail/msgbase/jam/fmail_help 2:221/6.600 (Loc)
Not a big deal, but perhaps windows version should write "\"
and linux version "/" to those export files. :)
grep fmail_help areas.*
areas.bbs:!\bbs\fmail\msgbase\jam\fmail_help FMAIL_HELP
2:221/6 areas.gld:AREADEF FMAIL_HELP "FMAIL_HELP" A Echo JAM /bbs/fmail/msgbase/jam/fmail_help 2:221/6.600 (Loc)
Those files can be written by 2 of the modules when auto export is executed. FConfig (which only exists as a Windows program), and
'FTools addnew -A'. I don't use the latter, but I think you might?
How is that path in your configuration? As a linux or as a windows version?
What I do, is have all my paths in windows form, and use the FMAIL_REPLACE_DRIVE environment variable for the linux modules.
And I have a little python script that converts the windows paths
in areas.gld to linux paths...
But it was strange that at the same time areas.bbs and areas.gld have different separator. :)
But it was strange that at the same time areas.bbs and areas.gld have
different separator. :)
I agree, if they both are written by the same program (FTools linux in this
case), the content should be consistent. I look into it...
Hi Tommi,
On 2023-01-27 12:28:46, I wrote to you:
But it was strange that at the same time areas.bbs and areas.gld have
different separator. :)
I agree, if they both are written by the same program (FTools linux in thisFound it and fixed it in the source. I'll let you know when an updated linux version is available...
case), the content should be consistent. I look into it...
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 994 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 97:12:19 |
| Calls: | 13,016 |
| Calls today: | 2 |
| Files: | 186,574 |
| Messages: | 3,282,095 |