• ipv6

    From Tommi Koivula@2:221/1.1 to Tony Langdon on Wed Jan 31 07:45:18 2018
    * Originally in ipv6
    * Crossposted in fmail_help

    31 Jan 18 09:05:00, you wrote to Michiel van der Vlist:

    BTW...

    @MSGID: 239.fido-ipv6@3:633/410 1ed58d3d

    My software (Fmail, Golded) does not like your not FTS-0009 complient
    MSGID. It breaks the reply linking.. :(

    Complain to the author of Synchronet. ;)

    It has been done. He doesn't care. ;(

    When using JAM, the bad format of MSGID doesn't matter, JAM has MSGIDcrc and REPLYcrc, which can be used in reply linking. "hpt link -j".

    How does Fmail handle the linking?

    'Tommi

    ... he.net certified sage
    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Wilfred van Velzen@2:280/464.112 to Tommi Koivula on Wed Jan 31 08:41:02 2018
    Hi Tommi,

    On 31 Jan 18 07:45, Tommi Koivula wrote to Tony Langdon:
    about: "ipv6":

    BTW...

    @MSGID: 239.fido-ipv6@3:633/410 1ed58d3d

    My software (Fmail, Golded) does not like your not FTS-0009
    complient MSGID. It breaks the reply linking.. :(

    Complain to the author of Synchronet. ;)

    It has been done. He doesn't care. ;(

    He does care! Because if he does change it, it will break existing code. The none standard synchronet MSGID is used internally in it's messagebase, afaik.

    In my opinion a wrong design decision to use the MSGID for this. But apparently
    difficult to fix...

    When using JAM, the bad format of MSGID doesn't matter, JAM has
    MSGIDcrc and REPLYcrc, which can be used in reply linking. "hpt link
    -j".

    How does Fmail handle the linking?

    It seems to work fine in jam messagebases when there are synchronet msgid's involved...


    Wilfred.

    --- FMail-W32 2.0.1.4
    * Origin: point@work (2:280/464.112)
  • From Tommi Koivula@2:221/0 to Wilfred van Velzen on Wed Jan 31 09:48:10 2018

    31 Jan 18 08:41, Wilfred van Velzen wrote to Tommi Koivula:

    @MSGID: 239.fido-ipv6@3:633/410 1ed58d3d

    My software (Fmail, Golded) does not like your not FTS-0009
    complient MSGID. It breaks the reply linking.. :(

    Complain to the author of Synchronet. ;)

    It has been done. He doesn't care. ;(

    He does care! Because if he does change it, it will break existing code. The none standard synchronet MSGID is used internally in it's messagebase, afaik. In my opinion a wrong design decision to use the MSGID for this. But apparently difficult to fix...

    Ok..

    When using JAM, the bad format of MSGID doesn't matter, JAM has
    MSGIDcrc and REPLYcrc, which can be used in reply linking. "hpt link
    -j".

    How does Fmail handle the linking?

    It seems to work fine in jam messagebases when there are synchronet
    msgid's
    involved...

    So Michiel is not using JAM ? Or how come his reply-linking isn't working ?

    'Tommi

    --- hpt/os2-emx 1.9.0-cur 17-02-17
    * Origin: 2001:470:1f15:cb0:f1d0:2:221:0 (2:221/0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Wed Jan 31 09:19:26 2018
    Hi Tommi,

    On 2018-01-31 09:48:10, you wrote to me:

    How does Fmail handle the linking?

    It seems to work fine in jam messagebases when there are synchronet
    msgid's involved...

    So Michiel is not using JAM ?

    He is, afaik.

    Or how come his reply-linking isn't working ?

    I don't know. ;)

    There is the "Update reply chains" option, but if you turn that off, it wouldn't work at all, not just for messages generated by synchronet.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Wed Jan 31 12:18:51 2018
    Hello Wilfred,

    On Wednesday January 31 2018 09:19, you wrote to Tommi Koivula:

    So Michiel is not using JAM ?

    He is, afaik.

    I use JAM.

    Or how come his reply-linking isn't working ?

    I don't know. ;)

    I think it is not Fmail that is the problem. The links were not worling when I reported it, but they are working now. It has happened before that links that do not work are restored the next day.

    My guess is that it is Golded. It is supposed to udate the reply links when responding to a message, but that seems to fail with non FTS-0009 MSGID. The daily run of ftools maint corrects it. I think...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/1.1 to Michiel van der Vlist on Wed Jan 31 14:16:52 2018
    I use JAM.

    Or how come his reply-linking isn't working ?

    I don't know. ;)

    I think it is not Fmail that is the problem. The links were not worling when I reported it, but they are working now. It has happened before that links that do not work are restored the next day.

    My guess is that it is Golded. It is supposed to udate the reply links
    when
    responding to a message, but that seems to fail with non FTS-0009 MSGID. The daily run of ftools maint corrects it. I think...

    My Golded updates the reply kludge just ok also with syncronet messages. And I can jump between messages with + and - .

    'Tommi

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Paul Quinn@3:640/1384 to Tommi Koivula on Wed Jan 31 22:38:03 2018
    Hi! Tommi,

    On 31 Jan 18 14:16, you wrote to Michiel van der Vlist:

    My guess is that it is Golded. It is supposed to udate the reply
    links when responding to a message, but that seems to fail with
    non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
    think...

    My Golded updates the reply kludge just ok also with syncronet
    messages. And I can jump between messages with + and - .

    Confirmed. Thread browsing around the IPv6 echo works a charm here too.

    Cheers,
    Paul.

    ... My other tagline is in the shop. This one is a loaner.
    --- GoldED+/LNX 1.1.5-b20110213
    * Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)
  • From Tommi Koivula@2:221/360 to Paul Quinn on Wed Jan 31 22:51:28 2018
    Paul Quinn wrote:

    On 31 Jan 18 14:16, you wrote to Michiel van der Vlist:

    MV>> My guess is that it is Golded. It is supposed to udate the reply
    MV>> links when responding to a message, but that seems to fail with
    MV>> non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
    MV>> think...

    TK> My Golded updates the reply kludge just ok also with syncronet
    TK> messages. And I can jump between messages with + and - .

    Confirmed. Thread browsing around the IPv6 echo works a charm here too.

    I meant "reply chain" when I wrote "reply kludge", but you got me right. :)

    'Tommi

    --- Sylpheed 3.6.0 (GTK+ 2.24.30; i686-pc-mingw32)
    * Origin: jamnntpd/linux/2 (2:221/360)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Wed Jan 31 22:02:42 2018
    Hello Tommi,

    On Wednesday January 31 2018 14:16, you wrote to me:

    My guess is that it is Golded. It is supposed to udate the reply
    links when responding to a message, but that seems to fail with
    non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
    think...

    My Golded updates the reply kludge just ok also with syncronet
    messages. And I can jump between messages with + and - .

    Windows vs Linux version?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/1.1 to Michiel van der Vlist on Thu Feb 1 09:06:14 2018

    31 Jan 18 22:02:42, you wrote to me:

    My guess is that it is Golded. It is supposed to udate the reply
    links when responding to a message, but that seems to fail with
    non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
    think...

    My Golded updates the reply kludge just ok also with syncronet
    messages. And I can jump between messages with + and - .

    Windows vs Linux version?

    Windows. Pretty much the same version you use, but W64:

    --- GoldED+/W32-MSVC 1.1.5-b20170303

    'Tommi

    --- GoldED+/W64-MSVC 1.1.5-b20170303
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Tommi Koivula@2:221/0 to Michiel van der Vlist on Thu Feb 1 09:30:10 2018

    01 Feb 18 09:06, Tommi Koivula wrote to Michiel van der Vlist:

    My Golded updates the reply kludge just ok also with syncronet
    messages. And I can jump between messages with + and - .

    Windows vs Linux version?

    Windows. Pretty much the same version you use, but W64:

    --- GoldED+/W32-MSVC 1.1.5-b20170303

    --- GoldED+/W64-MSVC 1.1.5-b20170303

    I have test echoes as .msg and squish also. Copied syncrobad messages to those echoes, replied to them and Golded updates reply chains 100% ok.

    Now with GoldED+/EMX 1.1.5-b20170303. :)

    'Tommi

    --- GoldED+/EMX 1.1.5-b20170303
    * Origin: ============================================== (2:221/0)
  • From Rob Swindell to Tommi Koivula on Sun Feb 4 18:58:50 2018
    Re: reply chains
    By: Tommi Koivula to Michiel van der Vlist on Thu Feb 01 2018 09:30 am

    I have test echoes as .msg and squish also. Copied syncrobad messages to those echoes, replied to them and Golded updates reply chains 100% ok.

    "syncrobad" - oh that's so witty of you.

    digital man

    Synchronet "Real Fact" #50:
    JAM and Squish were considered before developing Synchronet Message Base format.
    Norco, CA WX: 69.5°F, 34.0% humidity, 5 mph ESE wind, 0.00 inches rain/24hrs
  • From Nicholas Boel@1:154/10 to Rob Swindell on Sun Feb 4 22:57:28 2018
    Hello,

    On Sun, 4 Feb 2018 18:58:50 -0800, Rob Swindell -> Tommi Koivula wrote:

      Re: reply chains
      By: Tommi Koivula to Michiel van der Vlist on Thu Feb 01 2018 09:30 am

    ; I have test echoes as .msg and squish also. Copied syncrobad
    messages to those  echoes, replied to them and Golded updates
    reply chains 100% ok.

    "syncrobad" - oh that's so witty of you.

    Unfortunately, what most of these people don't realize is that Synchronet has far surpassed all of this software.

    If only any of them could keep up. ;)

    Regards,
    Nick

    --- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52
    * Origin: thePharcyde_ distribution system (1:154/10)
  • From Rob Swindell to Nicholas Boel on Sun Feb 4 21:51:17 2018
    Re: reply chains
    By: Nicholas Boel to Rob Swindell on Sun Feb 04 2018 10:57 pm

    Hello,

    On Sun, 4 Feb 2018 18:58:50 -0800, Rob Swindell -> Tommi Koivula wrote:

      Re: reply chains
      By: Tommi Koivula to Michiel van der Vlist on Thu Feb 01 2018 09:30 am

     >> I have test echoes as .msg and squish also. Copied syncrobad
    messages to those  echoes, replied to them and Golded updates
    reply chains 100% ok.

    "syncrobad" - oh that's so witty of you.

    Unfortunately, what most of these people don't realize is that Synchronet has far surpassed all of this software.

    I'll write up a FAQ about the stupid FTN MSG-ID standard and why Synchronet and SBBSecho generate unique FTN message IDs the way it does.

    Now there was a recent "bug" that was brought to my attention and fixed whereby SBBSecho was stripping trailing whitespace from imported kludge lines (including MSG-ID and REPLY control lines) and that caused a problem for some software when being exported back out to the net (a MSG-ID with a trailing space was considered *different* than another message with the same MSG-ID without a trailing space). Anway, that was "fixed" recently and really has nothing to do with the message-IDs generated by Synchronet/SBBSecho.

    If only any of them could keep up. ;)

    Competition is good but when the competitors just up and die on ya, what more can you do? :-)

    digital man

    Synchronet/BBS Terminology Definition #34:
    LF = Line Feed (ASCII 10, Ctrl-J)
    Norco, CA WX: 66.2°F, 42.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
  • From Wilfred van Velzen@2:280/464 to Rob Swindell on Mon Feb 5 09:50:55 2018
    Hi Rob,

    On 2018-02-04 21:51:17, you wrote to Nicholas Boel:

    I'll write up a FAQ about the stupid FTN MSG-ID standard and why Synchronet and SBBSecho generate unique FTN message IDs the way it
    does.

    So you are the only sane person in this world of stupid people? Where did I hear that before? ;)

    The MSGID standard is what it is. For whatever reason synchronet choose not to follow the standard. So don't be surprised that might cause some trouble on all
    other systems. Standards are there for a reason! So don't blame the others that
    follow it!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Rob Swindell to Wilfred van Velzen on Mon Feb 5 02:41:04 2018
    Re: Re: reply chains
    By: Wilfred van Velzen to Rob Swindell on Mon Feb 05 2018 09:50 am

    Hi Rob,

    On 2018-02-04 21:51:17, you wrote to Nicholas Boel:

    I'll write up a FAQ about the stupid FTN MSG-ID standard and why Synchronet and SBBSecho generate unique FTN message IDs the way it does.

    So you are the only sane person in this world of stupid people?

    No, I think only one person wrote FTS-9. I doubt he's stupid, but it's stupid that the spec was never clarified or updated to address its short-sightedness.

    Where did I hear that before? ;)

    I don't know. Where?

    The MSGID standard is what it is. For whatever reason synchronet choose not to follow the standard. So don't be surprised that might cause some trouble on all
    other systems. Standards are there for a reason! So don't blame the others that
    follow it!

    Actually, I did follow the standard. I even followed some existing practices that had been place for many years before Synchronet and its utilities (e.g. SBBSecho) started sending messages with unique MSGIDs into FidoNets.

    Here's my tired answer to this question: http://wiki.synchro.net/faq:misc#ftn_msgid

    digital man

    Synchronet/BBS Terminology Definition #30:
    IP = Internet Protocol
    Norco, CA WX: 61.8°F, 46.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
  • From Phil Taylor@1:275/201 to Tommi Koivula on Fri Oct 26 20:53:20 2018
    Complain to the author of Synchronet. ;)

    It has been done. He doesn't care. ;(


    Question: What version of fmail are you using?

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Mystic.dynu.net 2310 (1:275/201)
  • From Tommi Koivula@2:221/360 to Phil Taylor on Sat Oct 27 09:49:40 2018

    Friday October 26 2018 20:53, Phil Taylor wrote to Tommi Koivula:

    Question: What version of fmail are you using?

    | FMail/2 1.60 ¿ Setup Utility
    | Copyright (C) 1991, 2001 by Folkert J. Wijnstra ¿ All rights reserved

    Why?

    'Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/360)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sat Oct 27 11:53:56 2018
    Hi Tommi,

    On 2018-10-27 09:49:40, you wrote to Phil Taylor:

    | FMail/2 1.60 Setup Utility
    | Copyright (C) 1991, 2001 by Folkert J. Wijnstra All rights

    That's the OS/2 version isn't it? Otherwise I would strongly advise to upgrade to the latest opensource version! ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/360 to Wilfred van Velzen on Sun Oct 28 14:41:24 2018

    Saturday October 27 2018 11:53, Wilfred van Velzen wrote to Tommi Koivula:

    On 2018-10-27 09:49:40, you wrote to Phil Taylor:

    | FMail/2 1.60 Φ Setup Utility
    | Copyright (C) 1991, 2001 by Folkert J. Wijnstra Φ All rights

    That's the OS/2 version isn't it?

    That's what the /2 means. ;D

    Otherwise I would strongly advise to upgrade to the latest opensource version! ;)

    I know. ;) Well, the old setup of my FMail is just there, it's not "in production".

    'Tommi

    ---
    * Origin: 2001:470:1f15:cb0:f1d0:2:221:360 (2:221/360)
  • From Wilfred van Velzen@2:280/464.112 to Tommi Koivula on Mon Oct 29 10:35:22 2018
    Hi Tommi,

    On 28 Oct 18 14:41, Tommi Koivula wrote to Wilfred van Velzen:
    about: "ipv6":

    Otherwise I would strongly advise to upgrade to the latest opensource
    version! ;)

    I know. ;) Well, the old setup of my FMail is just there, it's not "in production".

    Pitty! ;)

    Wilfred.

    --- FMail-W32 2.0.1.4
    * Origin: point@work (2:280/464.112)
  • From Tommi Koivula@2:221/0 to Wilfred van Velzen on Mon Oct 29 17:24:58 2018
    On 29.10.2018 9:35, Wilfred van Velzen -> Tommi Koivula :

    Otherwise I would strongly advise to upgrade to the latest opensource
    version! ;)

    I know. ;) Well, the old setup of my FMail is just there, it's not "in
    production".

    Pitty! ;)

    No! I'm not going to delete it! :D

    BTW. FMail was my first-ever tosser when I was just a point. ;) There
    were fine offline readers like SLMR and QOmen, but the sysop of my
    favorite bbs (Express) persuaded me to set up a point. :D

    'Tommi

    ---
    * Origin: SmapiNNTPd/Linux-Pi 1.12 (2:221/0.0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Mon Oct 29 16:58:21 2018
    Hi Tommi,

    On 2018-10-29 17:24:58, you wrote to me:

    BTW. FMail was my first-ever tosser when I was just a point. ;) There
    were fine offline readers like SLMR and QOmen, but the sysop of my favorite bbs (Express) persuaded me to set up a point. :D

    As did mine. But I was using Amiga software when I was still a point. At some point I took over the bbs system of my boss, and that included FMail. The rest is history. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Carol Shenkenberger@1:275/100 to Tommi Koivula on Sat Nov 3 11:10:42 2018
    Re: ipv6
    By: Tommi Koivula to Wilfred van Velzen on Mon Oct 29 2018 05:24 pm

    BTW. FMail was my first-ever tosser when I was just a point. ;) There
    were fine offline readers like SLMR and QOmen, but the sysop of my favorite bbs (Express) persuaded me to set up a point. :D

    Innocent until proven guilty! (LOL!)

    xxcarol

    PS my first tosser was CONFMAIL
    --- SBBSecho 2.12-Win32
    * Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)
  • From Tommi Koivula@2:221/6 to Carol Shenkenberger on Sat Nov 3 22:08:52 2018
    Hi Carol.

    03 Nov 18 11:10:42, you wrote to me:

    BTW. FMail was my first-ever tosser when I was just a point. ;) There
    were fine offline readers like SLMR and QOmen, but the sysop of my
    favorite bbs (Express) persuaded me to set up a point. :D

    Innocent until proven guilty! (LOL!)

    * Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)

    :-D

    Anyways, the crime has expired in almost 30 years. :)

    'Tommi

    ---
    * Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)
  • From Carol Shenkenberger@1:275/100 to Tommi Koivula on Sat Nov 3 16:58:22 2018
    Re: ipv6
    By: Tommi Koivula to Carol Shenkenberger on Sat Nov 03 2018 10:08 pm

    of my favorite bbs (Express) persuaded me to set up a point. :D

    Innocent until proven guilty! (LOL!)

    * Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)

    :-D

    Anyways, the crime has expired in almost 30 years. :)

    Innocent still! I was feeding my first point in 1990.. oh dear!
    --- SBBSecho 2.12-Win32
    * Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)
  • From Ozz Nixon@1:275/362 to All on Thu Feb 7 18:02:53 2019
    Hello everybody.

    Recently (this week), I switched from Fastecho 1.46 to FMail 1.59b/Beta

    I am using JAMAPI Tools that allow me to inspect all files and how they are interact with the four files. Anyway, just to help others who may be looking to
    implement FMail, I can add fresh perspective.

    FMail works great with the JAM and Fidonet. It works with BSO folders.

    Only quirk(s) I have found:
    FMailW32 SCAN /J /S

    Works for getting messages out - that JAMNNTPD v1.2.3 is not always flaging posts as new, and updating the MODCOUNTER field in the header. (Which I assume FMail is using to know if there is anything to look for).

    The other quirk is my "INBOUND" and "OUTBOUND" are network folders. FMail reports the drive/path do not exist, create Y/n? So I make fake IN/OUT folders locally and I move my files IN/OUT before TOSS and SCAN.

    Other than that - I am using GoldED to also help me test. It has "I"nspect mode when you are scrolling through a message base (JAM, Fido/Opus, etc). Dumps
    the variables, headers, and hexdump of the actual content. Great (amazing) feature to put into an EDITOR!

    Ozz

    --- FMail/Win32 1.59b/beta
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Fri Feb 8 21:28:09 2019
    Hi Ozz,

    On 2019-02-07 18:02:53, you wrote to All:

    Recently (this week), I switched from Fastecho 1.46 to FMail
    1.59b/Beta

    Where did you even get that old beta version? You should switch to the latest and greatest!

    https://sourceforge.net/projects/fmail/files/FMail/2.0/FMailW32-2.0.1.zip/download

    But I'm collecting the old archives, so if you have the 1.59b release zip file I'm interested! ;)

    FMail works great with the JAM and Fidonet. It works with BSO
    folders.

    We know! ;)

    Only quirk(s) I have found:
    FMailW32 SCAN /J /S

    Works for getting messages out - that JAMNNTPD v1.2.3 is not always flaging posts as new, and updating the MODCOUNTER field in the header. (Which I assume FMail is using to know if there is anything to look for).

    I would have to look into that...

    The other quirk is my "INBOUND" and "OUTBOUND" are network folders. FMail reports the drive/path do not exist, create Y/n? So I make fake IN/OUT folders locally and I move my files IN/OUT before TOSS and SCAN.

    If the latest version still does that, we can try to debug that.

    But I'm using a N: drive which is a samba share on the linux side of my system from a virtual XP, which works flawlessly...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Paul Quinn@3:640/1384.125 to Wilfred van Velzen on Sat Feb 9 08:34:57 2019
    Hi! Wilfred,

    On 02/09/2019 06:28 AM, you wrote to Ozz Nixon:

    FMail works great with the JAM and Fidonet. It works with BSO
    folders.

    We know! ;)

    Still with a little too much Hudson. ;)

    Only quirk(s) I have found:
    FMailW32 SCAN /J /S

    Works for getting messages out - that JAMNNTPD v1.2.3 is not
    always flaging posts as new, and updating the MODCOUNTER field in
    the header. (Which I assume FMail is using to know if there is
    anything to look for).

    I would have to look into that...

    It may be directly unrelated but recall that "ftools maint" will renumber JAM messages, which up-fucks NNTP servers (JamNNTPd).

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Deja Booboo: The feeling you've screwed this up before. (3:640/1384.125)
  • From Wilfred van Velzen@2:280/464 to Paul Quinn on Sat Feb 9 00:19:27 2019
    Hi Paul,

    On 2019-02-09 08:34:57, you wrote to me:

    Only quirk(s) I have found:
    FMailW32 SCAN /J /S

    Works for getting messages out - that JAMNNTPD v1.2.3 is not
    always flaging posts as new, and updating the MODCOUNTER field in
    the header. (Which I assume FMail is using to know if there is
    anything to look for).

    I would have to look into that...

    It may be directly unrelated but recall that "ftools maint" will renumber JAM messages, which up-fucks NNTP servers (JamNNTPd).

    It's both about the jam messagebase, but that's where the similarities end. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Fri Feb 8 22:52:26 2019
    Hello Wilfred.

    08 Feb 19 21:28, you wrote to me:

    Firstly, KUDOS! Unzip 2.0 over 1.59b - run FTOOLS MAINT (AWESOME REPLY CHAIN FEATURE!!!!!) ... then ran the Config EXE - everything aligned perfectly, no wacky characters in fields or anything that other packages do - AWESOME UPGRADE!

    Per RETRO copies: http://archives.thebbs.org/ra53a.htm

    I am developing a new JAMAPI (TP version had a few quirks - no longer). I have also modernized it to current class/object structure. I will be incorporating your "Reply Chain" feature into the JAMAPI (I call DXJAMAPI to avoid confusion). I am also recoding QuickBBS v3.0 to support JAM - dropping GB and HMB. And I have been asked to recompile PCBoard 15.4 source (I will be releasing potentially this year too) - dropping CNAME design for JAM.

    * Only major wishlist I did not see (may be there) -- a drop file from FMail to
    me ECHOLIST with new posts via TOSS. And what is the best way for me to pass such from BBS/NNTP/etc to you for SCAN?

    Regards,
    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Ozz Nixon@1:275/362 to Ozz Nixon on Fri Feb 8 23:04:26 2019
    Hello Ozz.

    08 Feb 19 22:52, I wrote to Wilfred van Velzen:
    FMail to me ECHOLIST with new posts via TOSS. And what is the best way

    Realized that could also mean "NEW ECHO LIST"... but, mainly anything to shortcircuit time a BBS needs for "whats new" for users who actively read and write in the echos. I can then accumulate a list of ECHOS by DAY - and when a user logs back in - POOF there is almost real-time list of new ECHO POSTS, and I can use that for quickly FindNewByUser(UserCRC, UserID) which can pull from LastRead - or I could pre-create a list - all about making QuickBBS quicker...

    Again, thanks! Keep up the work! I have racks of servers with different OSes and APPs if you need a test bed, let me know. (I am good at finding bugs, and making them too) ;-)

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Tue Feb 12 21:42:07 2019
    Hi Ozz,

    On 2019-02-08 22:52:26, you wrote to me:

    Firstly, KUDOS! Unzip 2.0 over 1.59b

    "Unzip"? ;)

    - run FTOOLS MAINT (AWESOME REPLY CHAIN FEATURE!!!!!) ... then ran the Config EXE - everything aligned perfectly, no wacky characters in
    fields or anything that other packages do - AWESOME UPGRADE!

    Did the 1.59b do that? I don't think I ever used that beta version. The source I got from the original author was for 1.60. I did quite a bit of tweaking/improving/fixing/speeding-up on the maint code, but it's still based on the original by Folkert, so kudos must go to him too! ;)

    Per RETRO copies: http://archives.thebbs.org/ra53a.htm

    Thanks.

    I am developing a new JAMAPI (TP version had a few quirks - no
    longer). I have also modernized it to current class/object structure.
    I will be incorporating your "Reply Chain" feature into the JAMAPI (I
    call DXJAMAPI to avoid confusion).

    Well good luck with the porting from C to Pascal! ;)

    * Only major wishlist I did not see (may be there) -- a drop file from FMail to me ECHOLIST with new posts via TOSS.

    You mean something like what is in the toss log file but in a more machine readable form?

    And what is the best way for me to pass such from BBS/NNTP/etc to you
    for SCAN?

    Ehhrrr?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Tue Feb 12 21:51:33 2019
    Hi Ozz,

    On 2019-02-08 23:04:26, you wrote to you:

    FMail to me ECHOLIST with new posts via TOSS. And what is the best
    way

    Realized that could also mean "NEW ECHO LIST"... but, mainly anything to shortcircuit time a BBS needs for "whats new" for users who actively read and write in the echos. I can then accumulate a list of ECHOS by DAY - and when a user logs back in - POOF there is almost real-time list of new ECHO POSTS, and I can use that for quickly FindNewByUser(UserCRC, UserID) which can pull from LastRead - or I could pre-create a list - all about making QuickBBS quicker...

    Isn't that what the .jlr files in the JAM message base are for? They contain the last read "pointers" for each user, and they are updated everytime fmail updates the jam area files, as far as I remember...?

    Again, thanks! Keep up the work! I have racks of servers with
    different OSes and APPs if you need a test bed, let me know. (I am
    good at finding bugs, and making them too) ;-)

    Currently I and the single other test node, only use FMail with Binkly Style Outbound (BSO), and Golded as editor. And no bbs. So it could use some testing in other environments...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Thu Feb 14 10:09:08 2019
    Hello Wilfred.

    12 Feb 19 21:42, you wrote to me:

    Hi Ozz,


    I am developing a new JAMAPI (TP version had a few quirks - no
    longer). I have also modernized it to current class/object
    structure. I will be incorporating your "Reply Chain" feature
    into the JAMAPI (I call DXJAMAPI to avoid confusion).

    Well good luck with the porting from C to Pascal! ;)

    I do it all day ;-)

    * Only major wishlist I did not see (may be there) -- a drop file
    from FMail to me ECHOLIST with new posts via TOSS.

    You mean something like what is in the toss log file but in a more
    machine readable form?

    For example, d'Bridge tosser would let me know
    FTSC_PUBLIC
    FMAIL_HELP
    FN_SYSOP

    Which my BBS used to circumvent a full scan of 1000+ echos when someone would log in, that was on before the most recent toss - I limited their "NEW SCAN" to
    those 3 echos listed above. I have a small DB of userID,array of areas - so it only searched the array of areas from JLR forward. *MUCH* faster for a user on my systems... especially when I start pulling in newsgroups and any other FTN(etwork) I can get coming in.

    And what is the best way for me to pass such from BBS/NNTP/etc to
    you for SCAN?

    Same going out, I could drop SCANTHIS.LST and simply drop in:
    AREA or AREA,MSG#

    To short-circuit scanning for timestamp or modcounter changes in JAM.

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Thu Feb 14 10:14:50 2019
    Hello Wilfred.

    12 Feb 19 21:51, you wrote to me:

    Hi Ozz,

    Isn't that what the .jlr files in the JAM message base are for? They contain the last read "pointers" for each user, and they are updated everytime fmail updates the jam area files, as far as I remember...?

    Yes, but hitting 1000+ JLR files all over a drive *is slow* versus, SCANTHIS.LST from me to you - you only hit 5 to 10 echos that have been active since I signaled FMAIL SCAN.

    And vise versa, FMAIL and Rhenium run in a seperate thread/window from the BBS which is actually running right now behind GameSrv.exe in dynamic windows. * This will *SERIOUSLY* change when I migrate this to my Linux rack. However, in either case, I do not "SCAN" after every caller, and I do not "TOSS" after every mailer session. I am currently doing it on the 5's (every 5th minute I check if SCANTHIS.LST exists then I do a FMAIL SCAN) and if /BinkPDOS/IN/ has anythign other than . and .. then I call FMAIL TOSS.

    I do this, as I get 100's of port scans a minute that would normally trigger a "FMAIL TOSS" and really eat CPU... and depending upon their script - could cross-fire FMAIL SCAN if I ran it in the STARTBBS.BAT for GameSrv.exe

    Currently I and the single other test node, only use FMail with Binkly Style Outbound (BSO), and Golded as editor. And no bbs. So it could
    use some testing in other environments...

    If you do not mind *crazy* ideas to steamline my systems across the US - I will
    gladly share ideas. I can even share how d'Bridge does its folders - I call DBO
    for my environment (which supports both BSO and DBO concurrently)... MODEM vs BINKP. I am currently looking at scheduling a rewrite on Portal of Power, and merging my BinkPDOS code into it giving me EMSI/WAZOO/BINKP all on a single codebase (DOS/WINDOWS/MAC/LINUX).

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Thu Feb 14 22:43:31 2019
    Hi Ozz,

    On 2019-02-14 10:09:08, you wrote to me:

    * Only major wishlist I did not see (may be there) -- a drop file
    from FMail to me ECHOLIST with new posts via TOSS.

    You mean something like what is in the toss log file but in a more
    machine readable form?

    For example, d'Bridge tosser would let me know
    FTSC_PUBLIC
    FMAIL_HELP
    FN_SYSOP

    Which my BBS used to circumvent a full scan of 1000+ echos when someone would log in, that was on before the most recent toss - I limited their "NEW SCAN" to those 3 echos listed above. I have a small DB of
    userID,array
    of areas - so it only searched the array of areas from JLR forward. *MUCH* faster for a user on my systems... especially when I start pulling in newsgroups and any other FTN(etwork) I can get coming in.

    There's already this option in the config:

    Tossed Areas List

    Writes a list of echomail areas in which mail has been
    tossed to the specified file.

    I don't use it myself, but it seems just what you want.

    And what is the best way for me to pass such from BBS/NNTP/etc to
    you for SCAN?

    Same going out, I could drop SCANTHIS.LST and simply drop in:
    AREA or AREA,MSG#

    To short-circuit scanning for timestamp or modcounter changes in JAM.

    There is the "echomail.jam" that's read by fmail scan. Golded for instance creates it.

    Scan always

    If set to "Yes", the messages base will always be
    completely scanned for outgoing messages. If set to
    "No", FMail relies on the files ECHOMAIL.BBS and
    NETMAIL.BBS for Hudson and/or ECHOMAIL.JAM for JAM areas
    to indicate new messages. If these files are found to be
    pointing to a message that does not qualify for export,
    a complete scan of the message base (or JAM base) will
    be performed.

    (I hate to quote the docs, but there you go ;)).

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Thu Feb 14 22:56:13 2019
    Hi Ozz,

    On 2019-02-14 10:14:50, you wrote to me:

    Isn't that what the .jlr files in the JAM message base are for? They
    contain the last read "pointers" for each user, and they are updated
    everytime fmail updates the jam area files, as far as I remember...?

    Yes, but hitting 1000+ JLR files all over a drive *is slow*

    And would probably less then a second on a modern ssd drive. ;)

    versus, SCANTHIS.LST from me to you - you only hit 5 to 10 echos that
    have been active since I signaled FMAIL SCAN.

    And the options I mentioned in my previous message will do for this?

    And vise versa, FMAIL and Rhenium run in a seperate thread/window from
    the BBS which is actually running right now behind GameSrv.exe in
    dynamic windows. * This will *SERIOUSLY* change when I migrate this to
    my Linux rack. However, in either case, I do not "SCAN" after every caller, and I do not "TOSS" after every mailer session.

    I think you could. I don't run a bbs, so scan after a caller isn't an issue on my system. But I do run a toss after each mailer session. It's so fast, I don't
    have to give it another thought:

    wilnux5:/home/fido/log # grep 'Toss Active' fmail.log | tail
    21:10:08.860 Toss Active: 0.025 sec.
    21:12:17.939 Toss Active: 0.080 sec.
    21:13:15.650 Toss Active: 0.021 sec.
    21:14:39.782 Toss Active: 0.0051 sec.
    21:38:05.132 Toss Active: 0.030 sec.
    21:39:15.685 Toss Active: 0.030 sec.
    21:40:21.420 Toss Active: 0.044 sec.
    21:42:20.530 Toss Active: 0.0074 sec.
    21:59:15.780 Toss Active: 0.041 sec.
    22:03:12.721 Toss Active: 0.036 sec.

    I do this, as I get 100's of port scans a minute that would normally trigger a "FMAIL TOSS" and really eat CPU...

    I get hardly any port scans on the binkp port. And binkd only triggers a toss if there was a true mailer session, and pkt's received...

    Currently I and the single other test node, only use FMail with Binkly
    Style Outbound (BSO), and Golded as editor. And no bbs. So it could
    use some testing in other environments...

    If you do not mind *crazy* ideas to steamline my systems across the US - I will gladly share ideas.

    Ideas are ok, but I've very little time for working on fmail. Work, living, etc... ;)


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Fri Feb 15 10:36:32 2019
    Hello Wilfred.

    14 Feb 19 22:43, you wrote to me:

    There's already this option in the config:

    Tossed Areas List

    Writes a list of echomail areas in which mail has been
    tossed to the specified file.

    I don't use it myself, but it seems just what you want.

    * I didn't see that one, I saw:

    There is the "echomail.jam" that's read by fmail scan. Golded for
    instance creates it.

    Just not sure of the format - is that in the DOCs too???

    (I hate to quote the docs, but there you go ;)).

    I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but, assumed that was
    a RA 2.x feature and didn't want to go back through their STRUCT files to find it... thus, I asked. ;-)

    *I* do not mind making my products seamless with other solutions. My mailer has
    4 setting you change and d'Bridge becomes the tosser/manager. Since FMail is multi-platform also, I do not mind making the BBS and the MAILER work seamlessly with FMail...


    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Ozz Nixon@1:275/362 to Wilfred van Velzen on Fri Feb 15 10:43:23 2019
    Hello Wilfred.

    14 Feb 19 22:56, you wrote to me:

    wilnux5:/home/fido/log # grep 'Toss Active' fmail.log | tail

    C:\BBS\FMAIL>grep "Toss Active" TOSSER.LOG
    22:45:11 Toss Active: 0.015 sec.
    22:46:00 Toss Active: 0.171 sec.
    13:30:16 Toss Active: 2.125 sec.
    13:52:33 Toss Active: 0.172 sec.
    14:09:49 Toss Active: 0.171 sec.
    16:16:57 Toss Active: 0.203 sec.
    18:45:29 Toss Active: 0.203 sec.
    18:58:05 Toss Active: 0.218 sec.
    18:58:19 Toss Active: 0.203 sec.
    19:09:40 Toss Active: 7.884 sec.
    13:46:53 Toss Active: 0.313 sec.
    13:54:08 Toss Active: 4.218 sec.
    14:00:51 Toss Active: 0.218 sec.
    14:01:46 Toss Active: 1.859 sec.
    10:04:48 Toss Active: 1.860 sec.
    18:23:26 Toss Active: 1.781 sec.
    18:24:20 Toss Active: 0.406 sec.
    10:20:22 Toss Active: 1.616 sec.

    As you can see, it is not as fast as your Linux system, it is not bad though. The biggest delay is unpacking my daily digest of FSXNET. Those are the times FMail exceed a 1000ms.

    I do this, as I get 100's of port scans a minute that would
    normally trigger a "FMAIL TOSS" and really eat CPU...

    I get hardly any port scans on the binkp port. And binkd only triggers
    a toss if there was a true mailer session, and pkt's received...

    Correct, however, if I put FMail Scan in my STARTBBS.BAT - I would scan way too
    often. ;-)

    ** Off to research ECHOMAIL.JAM....

    Ozz

    --- FMail-W32 2.0.1.4
    * Origin: Richmond VA (RVA) Fidonet Support (1:275/362)
  • From Paul Hayton@3:770/100 to Ozz Nixon on Sat Feb 16 21:26:21 2019
    On 15 Feb 2019 at 10:43a, Ozz Nixon pondered and said...

    though. The biggest delay is unpacking my daily digest of FSXNET. Those are the times FMail exceed a 1000ms.

    That kind of makes me smile :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Sat Feb 16 12:04:49 2019
    Hi Ozz,

    On 2019-02-15 10:36:32, you wrote to me:

    There is the "echomail.jam" that's read by fmail scan. Golded for
    instance creates it.

    Just not sure of the format - is that in the DOCs too???

    I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but, assumed that was a RA 2.x feature and didn't want to go back through their
    STRUCT files to find it... thus, I asked. ;-)

    It's not in the fmail of golded docs. And my guess is, it's a RA thing...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Ozz Nixon on Sat Feb 16 12:41:11 2019
    Hi Ozz,

    On 2019-02-15 10:43:23, you wrote to me:

    wilnux5:/home/fido/log # grep 'Toss Active' fmail.log | tail

    C:\BBS\FMAIL>grep "Toss Active" TOSSER.LOG
    22:45:11 Toss Active: 0.015 sec.
    22:46:00 Toss Active: 0.171 sec.
    13:30:16 Toss Active: 2.125 sec.
    13:52:33 Toss Active: 0.172 sec.
    14:09:49 Toss Active: 0.171 sec.
    16:16:57 Toss Active: 0.203 sec.
    18:45:29 Toss Active: 0.203 sec.
    18:58:05 Toss Active: 0.218 sec.
    18:58:19 Toss Active: 0.203 sec.
    19:09:40 Toss Active: 7.884 sec.
    13:46:53 Toss Active: 0.313 sec.
    13:54:08 Toss Active: 4.218 sec.
    14:00:51 Toss Active: 0.218 sec.
    14:01:46 Toss Active: 1.859 sec.
    10:04:48 Toss Active: 1.860 sec.
    18:23:26 Toss Active: 1.781 sec.
    18:24:20 Toss Active: 0.406 sec.
    10:20:22 Toss Active: 1.616 sec.

    As you can see, it is not as fast as your Linux system, it is not bad though. The biggest delay is unpacking my daily digest of FSXNET. Those
    are
    the times FMail exceed a 1000ms.

    This might also be influenced by periodic tossing. In my case when I toss immediately after the mailer session. The received files are almost certainly still in memory caches. When you toss periodic, depending on how busy your system is, and the resources available, that might not be the case...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Paul Quinn@3:640/1384 to Wilfred van Velzen on Sat Feb 16 22:01:44 2019
    Hi! Wilfred,

    On 16 Feb 19 12:04, you wrote to Ozz Nixon:

    There is the "echomail.jam" that's read by fmail scan. Golded
    for instance creates it.

    Just not sure of the format - is that in the DOCs too???

    I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but,
    assumed that was a RA 2.x feature and didn't want to go back
    through their STRUCT files to find it... thus, I asked. ;-)

    It's not in the fmail of golded docs. And my guess is, it's a RA
    thing...

    It's known more widely. From what I've been able to find out in 5 minute's checking distro archives tossers like: CrahMail, FastEcho, FMail 1.22, GEcho, and the TimEd editor were aware of the file(s). Strangely Squish didn't. ;)

    Cheers,
    Paul.

    ... Whenever I get a grip on reality, the handle falls off.
    --- GoldED+/LNX 1.1.5-b20130515
    * Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Sat Feb 16 14:24:56 2019

    On 2019 Feb 16 12:04:48, you wrote to Ozz Nixon:

    I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but,
    assumed that was a RA 2.x feature and didn't want to go back through
    their STRUCT files to find it... thus, I asked. ;-)

    It's not in the fmail of golded docs. And my guess is, it's a RA thing...

    no... RA/FD/FE implemented it since they added it as part of a feature request... it was taken up by many others as well... the problem is that there are two or three similar files that provide the information but in slightly different ways... echomail.jam and netmail.jam are for _outbound_ local posts that need to be scanned out of the message base... some try to use this file for inbound which is the exact opposite of what it is intended for...

    the other files have another name and may be more generally used for "sole occupant" type setups like single user BBSes or point systems... especially those that use local sysop reader/editor setups like golded, timed, msged and similar... those can use those inbound files to sort those areas to the top of the mail listing if you want to see them first... i don't see them working very
    well for multi-user setups like a BBS with multiple users... the last read pointers of the users still need to be consulted no matter what mail arrived recently...

    on searching for new messages since a user's last visit, it should be easy enough for any JAM capable package to maintain the two lastread pointers for each user... it should also be able to quickly scan through the JLR files picking up and comparing the lastread pointers for each user with the number of
    messages in the area the JLR file is for... if a system is too slow doing that,
    they may want to examine their algorithm and/or system setup...

    i do recall, on DOS systems, that there was a major slowdown of scanning files which JAM brought to the forefront... the problem was actually in the file system and the way that the OS managed FAT* areas with large numbers of files... folks thought they were putting (eg) 400 message areas in one directory but they didn't realize they were really putting 1600 files in one directory... splitting the areas into directories with less than 255 _files_ (63 JAM areas) per directory sped the processing up by at least a magnitude...

    access speed problems may also be seen on networked drive shares... JAM really should be used from local fast HDs, IMHO...

    i like the OOP aspect of the pascal JAM library i used in my code... it was fast and did everything i needed... i don't know how non-OOP linear procedural code would work... if it would gather the needed information from the message base files as quickly or if additional requests would need to be made which could slow the scanning process down...

    FWIW: when i was using JAM, i was splitting my areas into a structured directory tree something like this...

    \FTNs\
    \FTNs\Fidonet\
    \FTNs\Fidonet\messages\
    \FTNs\Fidonet\messages\netmail\
    \FTNs\Fidonet\messages\echomail\
    \FTNs\Fidonet\messages\echomail\backbone\
    \FTNs\Fidonet\messages\echomail\backbone\1\
    \FTNs\Fidonet\messages\echomail\backbone\1\10th_amd.j*
    \FTNs\Fidonet\messages\echomail\backbone\A\
    \FTNs\Fidonet\messages\echomail\backbone\A\Alaska\Chat.j*
    \FTNs\Fidonet\messages\echomail\backbone\A\All\Politics.j*
    \FTNs\Fidonet\messages\echomail\backbone\A\Allfix\File.j*
    \FTNs\Fidonet\messages\echomail\backbone\A\Allfix\Help.j*
    [...]
    \FTNs\Fidonet\messages\echomail\backbone\B\
    \FTNs\Fidonet\messages\echomail\backbone\B\Bash.j*
    \FTNs\Fidonet\messages\echomail\backbone\B\Binkd.j*
    [...]
    \FTNs\Fidonet\messages\echomail\backbone\C\
    [...]
    \FTNs\Fidonet\files\FDNs\NODELIST\NODELIST.*
    \FTNs\Fidonet\files\FDNs\DAILYLIS.T\DAILYLST.*
    [...]
    \FTNs\Foobar\messages\netmail\
    \FTNs\FooBar\messages\echomail\backbone\A[...]
    \FTNs\FooBar\messages\echomail\backbone\B[...]
    \FTNs\FooBar\messages\echomail\backbone\C[...]
    \FTNs\FooBar\messages\echomail\backbone\D[...]

    it made things faster and also easier to maintain... autoadded areas were placed into a special directory for them until their record was updated in the tosser configuration program at which time it was moved to the proper directory
    in the above tree... i used whatever splitter was used between words as a divider... the ALLFIX_FILE and ALLFIX_HELP areas are good examples of that above... same with gated news groups where you use the dots between the portions of the group name as the directory splitter...

    eg: alt.bbs.ads -> [...]\alt\bbs\ads
    alt.comp.anti.virus -> [...]\alt.comp.anti.virus

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... You say I'm a bastard like it's a bad thing.
    ---
    * Origin: (1:3634/12.73)
  • From Ozz Nixon@1:275/362 to mark lewis on Sat Feb 16 19:32:20 2019
    On 2019-02-16 19:24:56 +0000, mark lewis -> Wilfred van Velzen said:

    i do recall, on DOS systems, that there was a major slowdown of
    scanning files which JAM brought to the forefront... the problem was
    actually in the file system and the way that the OS managed FAT* areas
    with large numbers of files... folks thought they were putting (eg) 400 message areas in one directory but they didn't realize they were really putting 1600 files in one directory... splitting the areas into
    directories with less than 255 _files_ (63 JAM areas) per directory
    sped the processing up by at least a magnitude...

    Luckily those limitations no longer exist :-)

    --
    +++ Are we having fun yet? I am!
    ATZ|ATDT911|1,2~555

    --- FMail-W32 2.0.1.4
    * Origin: ExchangeBBS WHQ (1:275/362.0)