• Mystic BBS v1.12 Alpha 34 Released

    From g00r00@21:1/108 to All on Friday, June 23, 2017 13:12:35
    Mystic v1.12 A34 is released on www.mysticbbs.com

    [---WHATSNEW---]

    ! Fixed a bug which could cause a bad memory reference error in various
    places within Mystic.

    ! MUTIL PostTextFile wasn't taking into consideration the tear and origin
    lines when posting to a networked base while splitting large posts into
    multiple messages.

    + -VER commandline option in Mystic now prints the OS information too.

    + Increased buffer size when writing message text to JAM bases to 32k up
    from 8k

    + Mystic JAM will no longer strip spaces from the right side of MSGID tags
    in JAM to help work around a bug with GTPower.

    ! JAM Reply CRC and Msg To CRC were not always converted to lower cased
    before calculated. As per JAM specs all CRC calculated on string must be
    lower cased first. Packing message bases will regenerate these.

    + Reduced the time it takes to calculate Message Index Reader statistics
    by about 60%. Statistics may be calculated incorrectly unless all bases
    have been ran through the message base packer once to regenerate CRC values

    ! Fixed a bug which could cause some node processes to not detect when a
    user hangs up, possibly resulting in a ghosted user or even a stuck
    process.

    + Added a new internal protocol Xmodem/CRC. This protocol can be added by
    creating @XMODEMCRC in your Protocl Configuration and has not had much
    testing. **This is experimental; it may or may not stick around**

    + When shutting down MIS2, it no longer prompts to press a key when closing
    but instead displays a "shutdown complete" message and pauses 1.5 seconds

    + When editing a file entry in a file base there is now a (H)atch command
    which allows files to be hatched to all networked systems linked to that
    file base. Files to be hatched will have a "Hatch pending" text or a
    Hatched flag if the request was already processed.

    + Mystic now creates "filebone.out" semaphore file whenever a new file is
    requested to be hatched.

    + MUTIL TIC processor will now scan for requested hatches. Any files
    requested to be hatched will have an appropriate TIC file created
    in each linked node's filebox, and the file will be copied to each
    linked node's filebox.

    + In addition to existing /E to view networked message bases linked to a
    node, the echomail node editor now has a /F to view and edit networked
    file bases linked to a node.

    + Significant stability improvements to MIS2 along with some minor cosmetic
    changes.

    ! Changed PKT addressing on pass-through echomail so that BBBS systems with
    its security feature enabled will not reject packets.

    + In the echomail nodes editor, when enabling a FileBox with a blank filebox
    location, Mystic will now give the option to automatically generate and
    create a directory for that node. The format used by Mystic for the
    directory is as follows:

    Root filebox directory = <mystic root path> + "/filebox/"

    Each directory is created under the root location with the format of:

    <domain>_z<zone>n<net>n<node> (p<point> appended only for points)

    Example for 21:1/108@fsxnet when installed to c:\mystic would be:

    c:\mystic\filebox\fsxnet_z21n1n108\

    <ALPHA 1.12 A34 RELEASED>

    --- Mystic BBS v1.12 A34 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 07:00:13
    On 06/23/17, g00r00 pondered and said...

    Mystic v1.12 A34 is released on www.mysticbbs.com

    [---WHATSNEW---]

    Thank you very much for this release, what an amazing addition to the Mystic feature set and user functionality - wow.. :)

    I have upgraded 1/100 HUB and used the HATCH feature to send out the latest binaries to FSX_MYST. As I type there's 90+ nodes getting their files sent
    out.

    The process to HATCH seemed very easy etc. and I'll likely have a few more questions soon about it. But for now I have picked up a problem.

    Files sent from A34 at 1/100 have landed at 1/101 (running A33) and are being rejected with a 'Bad File CRC' error for each.

    [snip]

    + Jun 24 06:37:01 Process: Toss FDN/TIC Files
    + Jun 24 06:37:01 Tossing FSXNET.tic
    + Jun 24 06:37:01 File FSXNET.Z74 Area FSX_NODE From 21:1/100
    - Jun 24 06:37:01 CRC 3ffdf650 TIC 000209af
    ! Jun 24 06:37:01 Bad file CRC; Moved to c:\bbs\files\bbs\badfile\
    + Jun 24 06:37:01 Tossing mys112a34_l32.tic
    + Jun 24 06:37:01 File mys112a34_l32.rar Area FSX_MYST From 21:1/100
    - Jun 24 06:37:01 CRC a69b4bbd TIC 0964b442
    ! Jun 24 06:37:01 Bad file CRC; Moved to c:\bbs\files\bbs\badfile\

    [snip]

    My hunch is others will report this also (but it will be interesting to see
    if it's just me).

    An example TIC I received that failed to toss looks like this.

    [snip]

    Created By Mystic BBS v1.12 A34
    Area FSX_NODE
    AreaDesc fsxNet Nodelist
    File FSXNET.Z74
    Size 6906
    CRC 000209af
    Replaces FSXNET.Z74
    Desc Weekly nodelist for fsxNet
    LDesc Weekly nodelist for fsxNet
    Path 21:1/100 Sat Jun 24 06:26:39 2017 UTC Mystic/1.12 A34
    Seenby 21:1/100
    Seenby 21:1/101
    Seenby 21:1/102
    Seenby 21:1/103
    Seenby 21:1/104
    Seenby 21:1/105
    Seenby 21:1/106
    Seenby 21:1/107
    Seenby 21:1/108
    Seenby 21:1/109

    [snip]

    Seenby 21:1/156
    Seenby 21:1/116
    Seenby 21:1/197
    Pw XXXXXXX <---- redacted
    To 21:1/101
    From 21:1/100

    [snip]

    The 1/100 HUB is running on Win 32

    To HATCH I had imported the files using the inbuilt mass uploader in the file menu and then run the file list editor to hatch each. I did not ask the
    system to generate a REPLACE verb in each instance of hatching.

    Level 3 logging at the HUB reveals little but suggests all went well when
    MUTIL was run.

    [snip]

    + Jun 24 06:32:17 Process: Toss FDN/TIC Files
    + Jun 24 06:32:17 Scanning Hatches
    + Jun 24 06:32:17 Hatching: mys112a34_l32.rar from Mystic BBS Software
    + Jun 24 06:32:17 Tossing to 21:1/101
    + Jun 24 06:32:17 Tossing to 21:1/105
    + Jun 24 06:32:17 Tossing to 21:1/103
    + Jun 24 06:32:17 Tossing to 21:1/113

    [snip]

    + Jun 24 06:32:24 Tossing to 21:1/185
    + Jun 24 06:32:24 Tossing to 21:1/189
    + Jun 24 06:32:24 Results: 0 import, 378 toss, 7 hatch, 0 bad in 7.60s

    [snip]

    I did nor run any base packing prior to first attempt. I note the following

    [snip]

    ! JAM Reply CRC and Msg To CRC were not always converted to lower cased
    before calculated. As per JAM specs all CRC calculated on string must be
    lower cased first. Packing message bases will regenerate these.

    [snip]

    Could changes you made in this space be leading to issues in file hatch CRC problems I'm now seeing in the Mystic .TICs ?

    Best, Paul

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Friday, June 23, 2017 15:45:22
    Could changes you made in this space be leading to issues in file hatch CRC problems I'm now seeing in the Mystic .TICs ?

    No its just that the CRC function is broken. Crap... Sorry. I'll have to do some testing to get it fixed up and get an A35 out sooner than later.

    In the meantime if anyone has suggestions for improving hatching please let me know. I know people want announcements which I hope to do soon. I just have to research and refresh my memory on how those are usually handled in things like AllFix etc.

    One idea I have is to be able to flag a file base as "automatically hatch all new files" and then MUTIL will automatically hatch any new files added to
    that file area when they are added.

    This could be dangerous though if someone made a mistake and uploaded a ton
    of files, they could end up hatching a lot of files. I am not sure if this
    is a feature that people would use?

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From g00r00@21:1/108 to Avon on Friday, June 23, 2017 15:52:40
    Files sent from A34 at 1/100 have landed at 1/101 (running A33) and are being rejected with a 'Bad File CRC' error for each.

    I have a new mutil.rar at www.mysticbbs.com/downloads/mutil.rar

    This is a Win32 version which may fix the CRC problem.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 08:04:28
    On 06/23/17, g00r00 pondered and said...

    Could changes you made in this space be leading to issues in file hat CRC problems I'm now seeing in the Mystic .TICs ?

    No its just that the CRC function is broken. Crap... Sorry. I'll have
    to do some testing to get it fixed up and get an A35 out sooner than later.

    Ah gotcha thanks :)

    I must say these day/time zone differences seem to work quite well at times, I'm often just getting up (early today_) and able to get things out quite quickly when I suspect your heading off to zzz or it's later on a Friday
    there? Saturday morning here around 7.50am as I type this reply.


    In the meantime if anyone has suggestions for improving hatching please let me know. I know people want announcements which I hope to do soon.
    I just have to research and refresh my memory on how those are usually handled in things like AllFix etc.

    Yep a text file that MUTIL can post or similar would be great.

    One idea I have is to be able to flag a file base as "automatically
    hatch all new files" and then MUTIL will automatically hatch any new
    files added to that file area when they are added.

    This could be dangerous though if someone made a mistake and uploaded a ton of files, they could end up hatching a lot of files. I am not sure
    if this is a feature that people would use?

    I think that could be dangerous at least at present there needs human involvement to press a key to hatch things.

    I'll ponder that some more.

    The concern I have is how to avoid (from a HUB perspective) nodes being able
    to freely hatch stuff to network file echos and the HUB simply accepting those incoming TICs and promulgating them out again to other connected nodes
    without any HUB admin ability to moderate this process (if desired)?

    Whilst I'm aware some some FTN networks have an accepted 'upload' file echo
    I'm unsure if that would really even work to negate the issue I describe
    above.

    There does seem to be only one way of getting at the actual hatch process
    right now (via file list editor - right?) so building a MUTIL function with some options to point to a file dir and file base ID# could be one option (again not sure of wisdom of this) or adding a menu command to toggle a file being display for hatching on/off ... just thinking out loud here... or something in the file index lister or just the file listing view for users
    with correct ACS to be able to tag files for hatching much like users tag
    them for bulk download....

    I'll keep pondering.

    Glad we picked up the CRC thing quickly. :)

    Best, Paul

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 08:08:34

    On 06/23/17, g00r00 pondered and said...

    I have a new mutil.rar at www.mysticbbs.com/downloads/mutil.rar

    This is a Win32 version which may fix the CRC problem.

    Thanks, grabbed, it now testing with a test hatch of fsxNet infopack... will let you know.

    Best, Paul

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 08:15:17
    On 06/24/17, Avon pondered and said...

    I have a new mutil.rar at www.mysticbbs.com/downloads/mutil.rar

    This is a Win32 version which may fix the CRC problem.

    Thanks, grabbed, it now testing with a test hatch of fsxNet infopack... will let you know.

    Best, Paul

    Nope, sadly the same..

    [snip]

    - Jun 24 08:11:40 SKIP PackFileBases
    + Jun 24 08:11:40 Process: Toss FDN/TIC Files
    + Jun 24 08:11:40 Tossing fsxinfo.tic
    + Jun 24 08:11:40 File fsxinfo.zip Area FSX_INFO From 21:1/100
    - Jun 24 08:11:40 CRC 0e1fcaca TIC fe1fcaca
    ! Jun 24 08:11:40 Bad file CRC; Moved to c:\bbs\files\bbs\badfile\
    + Jun 24 08:11:40 Results: 0 imported, 0 tossed, 1 bad in 0.00s
    + Jun 24 08:11:40 Process: Importing EchoMail
    + Jun 24 08:11:40 Waiting for BUSY nodes

    [snip]

    Thats from my A33 BBS after A35 tossing at 1/100

    [snip]

    ----------------- MUTIL v1.12 A35 Sat, Jun 24 2017 (loglevel 3)
    + Jun 24 08:10:28 Startup using mailin.ini
    - Jun 24 08:10:28 SKIP Import_FIDONET.NA
    - Jun 24 08:10:28 SKIP Import_MessageBase
    - Jun 24 08:10:28 SKIP Import_FILEBONE.NA
    - Jun 24 08:10:28 SKIP MassUpload
    - Jun 24 08:10:28 SKIP GenerateTopLists
    - Jun 24 08:10:28 SKIP Import_FILES.BBS
    - Jun 24 08:10:28 SKIP GenerateAllFiles
    - Jun 24 08:10:28 SKIP ExportEchoMail
    - Jun 24 08:10:28 EXEC ImportEchoMail
    - Jun 24 08:10:28 SKIP PurgeMessageBases
    - Jun 24 08:10:28 SKIP PackMessageBases
    - Jun 24 08:10:28 SKIP PostTextFiles
    - Jun 24 08:10:28 SKIP LinkMessages
    - Jun 24 08:10:28 SKIP MergeNodeLists
    - Jun 24 08:10:28 EXEC FileToss
    - Jun 24 08:10:28 SKIP PackFileBases
    + Jun 24 08:10:28 Process: Toss FDN/TIC Files
    + Jun 24 08:10:28 Scanning Hatches
    + Jun 24 08:10:28 Hatching: fsxinfo.zip from fsxNet Infopack
    + Jun 24 08:10:28 Tossing to 21:1/101
    + Jun 24 08:10:28 Tossing to 21:1/102

    [snip]

    Best, Paul

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Friday, June 23, 2017 16:38:08
    loud here... or something in the file index lister or just the file listing view for users with correct ACS to be able to tag files for hatching much like users tag them for bulk download....

    This is something I was planning to do (its the reason hatch ACS is already there). I thought I'd have a (H)atch option right in the file lister, and anyone with the Hatch ACS can hatch files they select.

    I think you're right about keeping hatching manual for now.

    As far as announcements, should Mystic just track any files that are received by .TIC and then create an announcement of all files received since the last time an announcement was made? What should it do for hatched files?

    Do systems ever announce files that aren't part of file echos? My thoughts are that any files received via .TIC files OR hatched by the SysOp would be included in the announcement.

    This isn't something I've ever done with Allfix or anything else, so I'm not clear on exactly how people typically use announcements.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From g00r00@21:1/108 to Avon on Friday, June 23, 2017 16:39:00
    Nope, sadly the same..

    Okay thanks. Back to the drawing board. I'll setup a system here to test
    with so I can get it right. I thought I saw the problem right away but I
    guess not.

    I'll have another one available within the next day

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 10:26:21
    On 06/23/17, g00r00 pondered and said...

    Okay thanks. Back to the drawing board. I'll setup a system here to
    test with so I can get it right. I thought I saw the problem right away but I guess not.

    I'll have another one available within the next day

    No rush at all.. I'm bunking off my current TO-DO weekend list from my wife
    to reply etc. so I understand it's just a hobby ... a good one ... but still something we do as and when we can :)

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 10:42:47
    On 06/23/17, g00r00 pondered and said...

    This is something I was planning to do (its the reason hatch ACS is already there). I thought I'd have a (H)atch option right in the file lister, and anyone with the Hatch ACS can hatch files they select.

    Yep seems reasonable to me, but do ponder the points I raised about HUB operators wanting to moderate hatched flows from nodes if so desired. Else it could be an uncontrolled free for all which worries me a bit. Perhaps I'm
    being to anal about that?

    I think you're right about keeping hatching manual for now.

    For now, yep :)

    As far as announcements, should Mystic just track any files that are received by .TIC and then create an announcement of all files received since the last time an announcement was made? What should it do for hatched files?

    Yes I think that's the way to go.

    I would allow the sysop to edit a template file so they adjust the layout of info like file size, date hatched, original system sending address etc.
    Perhaps something that allows sorting of hatched files by size, file name
    etc. for those of us with OCD that like order etc. Hah!

    Something that could show files hatched by file base group so all the fsxNet then all Fidonet etc.

    Do systems ever announce files that aren't part of file echos? My

    Not via echomail that I know of but I like the idea of having that option.

    thoughts are that any files received via .TIC files OR hatched by the SysOp would be included in the announcement.

    Agreed :) Good place to start then finesse. Suggest a .ini file to allow customization is the way to go and likely to be the subsequent focus of requests to add additional template codes etc. in to as sysops seek
    additional ways to slice and dice info and present in the custom
    announcements.

    This isn't something I've ever done with Allfix or anything else, so I'm not clear on exactly how people typically use announcements.

    I have sent you a zip file via filebox with the allfix docs and some example template files it ships with to give you a feel for things there :)

    With HTick it just takes a copy of the file_id.diz and puts in in a file you specify which gets posted to the message base you wish. I have also sent you
    an html file with the htick docs that reference it's announce functionality.

    Hope that all helps :)

    Best, Paul

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Friday, June 23, 2017 20:30:21
    Yep seems reasonable to me, but do ponder the points I raised about HUB operators wanting to moderate hatched flows from nodes if so desired.
    Else it could be an uncontrolled free for all which worries me a bit. Perhaps I'm being to anal about that?

    Well, the hatching from the file list should generally be a sysop-only function. I would probably default new areas to set that to "s255" in the future.

    The ACS is there because (for example), you may want to give just *me* access to hatch in the Mystic file areas from your BBS - so I could call in and upload new releases and hatch them immediately... Things like that.

    Remember we can specify specific users within ACS strings... so this will allow us to assign certain people or groups of people who can moderate and hatch within individual file bases. Or we can just keep it s255 and only the Sysop does it.

    Something that could show files hatched by file base group so all the fsxNet then all Fidonet etc.

    Yep, we absolutely want some way to do this. I am curious as to how Allfix (or other utilities) define/separate this information...

    Of the top of my head: Maybe we do it by echomail address, since each base is assigned to an echomail address specific to a network:

    announce.exe <echomail domain> <base IDs to post>

    announce fsxnet 1,64,23,2

    ^^ posts the announcement for all new files that came into any file base configured to the fsxnet domain to message base #1, 64, 23, and 2. Those announced files are then removed from the "announcement" database.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Saturday, June 24, 2017 19:53:04
    On 06/23/17, g00r00 pondered and said...

    Well, the hatching from the file list should generally be a sysop-only function. I would probably default new areas to set that to "s255" in
    the future.

    The ACS is there because (for example), you may want to give just *me* access to hatch in the Mystic file areas from your BBS - so I could call in and upload new releases and hatch them immediately... Things like that.

    Remember we can specify specific users within ACS strings... so this
    will allow us to assign certain people or groups of people who can moderate and hatch within individual file bases. Or we can just keep it s255 and only the Sysop does it.


    Yep all understood but... there's nothing in place as far as I can tell to enable any file hatching moderation (perhaps the wrong word but I think you
    get the gist of what I am trying to say) of files being sent out to all nodes in a network by anyone with a connection to a HUB file base.

    Yep, we absolutely want some way to do this. I am curious as to how Allfix (or other utilities) define/separate this information...

    Of the top of my head: Maybe we do it by echomail address, since each
    base is assigned to an echomail address specific to a network:

    announce.exe <echomail domain> <base IDs to post>

    announce fsxnet 1,64,23,2

    ^^ posts the announcement for all new files that came into any file base configured to the fsxnet domain to message base #1, 64, 23, and 2. Those announced files are then removed from the "announcement" database.


    Sounds good, I think also something that can track overall file hatching
    stats over a period of time based on those announce.exe sessions. So if you want to report on total numbers of files hatched by echomail domain by
    file echo for the last 30,60,90 days you can get it. It would mean some
    stats data would need to be saved from each announce.exe session to ensure
    over a period of time you could still pull such reports. Maybe it's a config setting somewhere to enable days of activity retained or some such? Just another random idea :)

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Saturday, June 24, 2017 08:20:47
    Yep all understood but... there's nothing in place as far as I can tell
    to enable any file hatching moderation (perhaps the wrong word but I
    think you get the gist of what I am trying to say) of files being sent
    out to all nodes in a network by anyone with a connection to a HUB file base.

    Do you mean in a case where another BBS (say mine for example) hatches a file in FSX_INFO and it gets sent to you, then your BBS will toss it all of the downlinks? I can see how that is a problem. What does Allfix do to prevent this?

    We could put a flag on a file base to prevent Mystic for tossing any files that come in for that area to downlinks. "FileEcho Hub" Yes/No if set to Yes then only files that are hatched from your BBS will be sent down. Files that arrive for that area will be added to your file base, but not tossed to downlinks unless you manually hatch it yourself. What do you think?

    Sounds good, I think also something that can track overall file hatching stats over a period of time based on those announce.exe sessions. So if you want to report on total numbers of files hatched by echomail domain
    by file echo for the last 30,60,90 days you can get it. It would mean

    I think maybe what I will do is have it create a database of say the last 10,000 files to come through. The database will just have an "announced" flag so when you announce that particular file it gets set so that it won't get announced again.

    This will give us a history of the last 10,000 files to report on which should easily cover the 90 days.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Sunday, June 25, 2017 15:07:58
    On 06/24/17, g00r00 pondered and said...

    Yep all understood but... there's nothing in place as far as I can te to enable any file hatching moderation (perhaps the wrong word but I think you get the gist of what I am trying to say) of files being sen out to all nodes in a network by anyone with a connection to a HUB fi base.

    Do you mean in a case where another BBS (say mine for example) hatches a file in FSX_INFO and it gets sent to you, then your BBS will toss it all of the downlinks? I can see how that is a problem. What does Allfix do to prevent this?

    Yes that's correct. Allfix allows nodes to be configured as being able to
    send and/or receive files. You see this at the file base level when adding a node to a file base and also set things at a file group level.

    The way it seems to work is that you can (at a group level) set default systems (nodes) to be members of the file group.

    You can also just add and remove nodes at a file base level too.

    But against those nodes set up in Allfix each has settings like this


    [snip]

    Source: ALLFIX version 6.00 Docs

    ---

    Downlink systems need to be selected in several portions of the configuration program. The Ins key can be used to add a system to the list and the Del key can be used to remove one. The menu to add or edit a
    system in the systems list contains the following fields:

    Node Address

    This field contains the network address of the system.
    SysOp
    This field contains the name of the SysOp of the above
    entered system. This option can also be used to select a
    system from the list of systems configured in the Node
    manager.

    The following five fields are only available in the fileecho
    manager:

    Send files

    This field determines if this system should receive files.

    Inactive

    This field determines if this system is temporarily inactive
    or not, ie. whether or not it receives files if the above
    option is set to Yes.

    Receive file
  • From g00r00@21:1/108 to Avon on Sunday, June 25, 2017 09:47:30
    That's one way of doing it and I think it could work. As mentioned above it seems like Allfix is more granular in it's permitted control over
    nodes and file groups to allow send and/or receive at those levels too.

    I went ahead and added the "File Hub" flag which means that it will not toss any incoming files to that area at all from any downlinks, but I can see how doing that on a per-node basis might be good too.

    I want to see if I can make it as easy to manage as possible, so we don't have to jump to a bunch of different places in order to set things up.

    I do like the idea of groups. I'll have to think about how we can enhance
    both echomail and filemail to include some sort of group system without
    making it too convoluted.

    --- Mystic BBS v1.12 A35 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Monday, June 26, 2017 13:15:39
    On 06/25/17, g00r00 pondered and said...

    I went ahead and added the "File Hub" flag which means that it will not toss any incoming files to that area at all from any downlinks, but I
    can see how doing that on a per-node basis might be good too.

    I want to see if I can make it as easy to manage as possible, so we
    don't have to jump to a bunch of different places in order to set things up.

    I do like the idea of groups. I'll have to think about how we can
    enhance both echomail and filemail to include some sort of group system without making it too convoluted.

    Good stuff, thanks. Yes I agree the notion of groups is worth exploring and implementing something for Mystic. As I wrote my previous reply to you I also found myself thinking all of the ideas being mooted were equally applicable
    for echomail from a HUB operations perspective also.

    e.g some echo ares like an admin one you don't want nodes to un-subscribe from or if a HUB carries access to a number of message groups then it is able to
    set which groups nodes can subscribe to etc.

    More stuff to ponder :)

    --- Mystic BBS v1.12 A33 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Friday, February 01, 2019 16:55:02
    On 31 Jan 2019, g00r00 pondered and said...

    So do you think there should be an [AutoHatch] stanza in MUTIL? Or
    should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"

    I think both but in order of effort I would do MUTIL first as most are
    familiar with it. But I know you want to roll things into MIS so it's worth doing so down the track.

    I am a little hesitant on this one just because of someone accidentally wildcarding and hatching 1000 files without realizing it, particularly if we're going to put it into MUTIL.

    I'm understanding of that. Yep best to park. If the sysop can load stuff to a text file and MUTIL honours that then that would be fine.

    rather sit on hold until the node polls... some setting like filebox autohold if file size > x Kb

    I've actually added this already its just not showing in the
    configuration because I've never tested it. I am going to enable this
    now and it will be in the next build but probably still untested by me.

    Heh good to know I'm not the only one pondering this. :)

    Also the next build has a minor change in the function that receives data during BINKP transfers. It seems to be working fine for me on my BBS
    but I just wanted to mention it so you are in the loop. Obviously binkp actually working is a big deal for you. :)

    It is thanks, I'll pull it down and check things out tonight when I get home.

    I'll go ahead and make a new build now for you.


    Thank you.

    a way to ensure those systems did crash any/all messages/files if the echonode was so set to do so.

    It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.

    Then that's sounding ideal - thanks!

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Friday, February 01, 2019 07:50:41
    I think both but in order of effort I would do MUTIL first as most are familiar with it. But I know you want to roll things into MIS so it's worth doing so down the track.

    Sounds good I will look into adding this into MUTIL first.

    I really need to get those BSY files into the TIC processor though because if a file is in mid-transmission and mutil is executed, it will toss a partial file. It doesn't happen often but a few people have reported this happening in the past. Instances of this will only increase as we build out more features!

    rather sit on hold until the node polls... some setting like fil autohold if file size > x Kb

    I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enable thi now and it will be in the next build but probably still untested by m

    Heh good to know I'm not the only one pondering this. :)

    Nope this was all your idea! You had mentioned it to me some time ago and I thought it was a great idea, so you get all the credit! :)

    It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.

    Then that's sounding ideal - thanks!

    Now we just have to get that global echomail node editor in there!

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From g00r00@21:1/108 to Avon on Friday, February 01, 2019 08:47:05
    So do you think there should be an [AutoHatch] stanza in MUTIL? Or should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"

    I think both but in order of effort I would do MUTIL first as most are familiar with it. But I know you want to roll things into MIS so it's

    There are some things to work through before I add this feature. To hatch a file as it stands now, it must already exist in the file area and Mystic hatches based on that data. The main reason that Mystic does this is so that it can track the status of a file (if its been hatched before) but it also pulls the file description from there too.

    Do we want Mystic to hatch without the requirement of having to have a file in the base? Should it upload it to the base if it doesn't exist and then hatch, or should it just require that it already exists before it will hatch?

    My thoughts are that if you're going to hatch a file it should require it to actually be in the file listing for that file echo otherwise you can hatch files out that don't even exists in the hub's file base.

    Here is what I am thinking as far as what it'd look like in MUTIL

    [AutoHatch]

    ; List of files to hatch automatically when executed
    ; Format: Area ID or echotag, filename, replaces filename (optional)
    ; All fields are separated by a pipe character |

    file = fsx_info | fsxinfo.zip | fsxinfo.zip
    file = 10 | fsxnode.zip | fsxnode.zip

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Saturday, February 02, 2019 08:43:15

    On 01 Feb 2019, g00r00 pondered and said...

    Do we want Mystic to hatch without the requirement of having to have a file in the base? Should it upload it to the base if it doesn't exist
    and then hatch, or should it just require that it already exists before
    it will hatch?

    For what we are talking about with the AutoHatch function, yes I agree with
    you and think the latter option.

    My thoughts are that if you're going to hatch a file it should require
    it to actually be in the file listing for that file echo otherwise you
    can hatch files out that don't even exists in the hub's file base.

    I also agree with this for using the AutoHatch feature but...when you are a
    HUB and just wanting to import new files into the system and get them hatched as quickly and easily as possible I think it's a good idea for us to find an acceptable way to do this also.

    Here's what I need to do at the moment if I wish to use Mystic for hatching a file.

    I opted to follow the process of finding a new file, dropping it in to
    fsx_utls file directory on the local HDD, logging into the HUB, and running
    the mass upload option from the file menu for the fsx_utils base.

    [snip]

    2019.02.02 07:10:05 Avon logged in
    2019.02.02 07:10:05 First login today, setting time to 999
    2019.02.02 07:10:05 Set time left 999 TE=1429
    2019.02.02 07:10:05 Setting time left to 999
    2019.02.02 07:10:37 Mass upload
    2019.02.02 07:10:45 Added xsdl2crt.zip to BBS Utils, Tools, Networking etc. 2019.02.02 07:10:45 Executing: unzip -oqqjC "c:\mystfsx\files\fsx_utls\xsdl2crt.zip" "file_id.*" -d c:\mystfsx\temp1\ 2019.02.02 07:10:45 Execution complete: 0
    2019.02.02 07:11:28 User logged off
    2019.02.02 07:11:28 Shutting down

    [snip]

    Then I confirmed calling the filetoss stanza did nothing at this point to
    send it on to the 50+ echonodes linked to the base... and it didn't, which is to be expected.

    [snip]

    ----------------- MUTIL v1.12 A42 2018/12/30 Sat, Feb 02 2019 (loglevel 3)
    + Feb 02 07:11:55 Startup using mailin.ini
    - Feb 02 07:11:55 EXEC ImportEchoMail
    - Feb 02 07:11:55 EXEC FileToss
    + Feb 02 07:11:55 Process: Toss FDN/TIC Files
    + Feb 02 07:11:55 Scanning Hatches
    + Feb 02 07:11:55 Results: 0 import, 0 toss, 0 hatch, 0 bad in 0.02s

    [snip]

    and then reconfirming what I already knew, that to hatch from mystic I'd need login to the HUB, head to the file menu, select the correct file base, go in
    to file list editor option, find the file, choose H to hatch, step through
    the hatch options manually to confirm the hatch, logout, then call the
    filetoss stanza to get the files on their way to nodes.

    And to be honest that's a pain to do for one or more files, which is why at
    the moment when I hatch things I use an external TIC generation tool to
    create something for Mystic to ingest that handles both import into the file base and tossing and hatching to connected nodes all in one hit... much
    easier.

    So I'd like to ask for an option one also- Mystic to upload to the base and hatch. But this should be something separate from what we're
    brainstorming as a AutoHatch function in MUTIL.

    I'm wondering perhaps it can be something added to the MassUpload function so there's a hatch switch?

    ; Hatch files to FileEcho exports? 1=yes

    hatch_file_echo_exports = 1


    Or if this is seen to be too risky for a mass file bombing run (and I accept there's risk) then finding someway that a HUB operator can run a mystic
    command or switch to make possible what at present requires a bit of a kludge to achieve. I hope that all makes sense.. sing out if it does not :)

    [AutoHatch]

    ; List of files to hatch automatically when executed
    ; Format: Area ID or echotag, filename, replaces filename (optional)
    ; All fields are separated by a pipe character |

    file = fsx_info | fsxinfo.zip | fsxinfo.zip
    file = 10 | fsxnode.zip | fsxnode.zip

    Yep like this, just add a comment about case of file names, I'm presuming if the sysop put in FSXinfo.zip or FSXINFO.ZIP then Mystic would still hatch the correct file? I wonder if some default treatment of file names being hatched should be enabled?

    ; Convert filenames to lower case for hatched files?
    ; True or 1 for yes, false or 0 for no

    lowercase_filename = true

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Friday, February 01, 2019 16:46:22
    And to be honest that's a pain to do for one or more files, which is why at the moment when I hatch things I use an external TIC generation tool
    to create something for Mystic to ingest that handles both import into
    the file base and tossing and hatching to connected nodes all in one hit... much easier.

    This is my process for hatching a bunch of brand new files now:

    If you have 5 files to hatch into an area you copy them into the folder, login to the BBS, type /U on the file menu, then do a newscan of the base. The 5 new files will show up, with the first one already highlighted. Press E to edit, then select hatch press ] to go to the next file, then select hatch, ] hatch ] hatch. It should only take about a minute or two to hatch those files.

    From a command line you'll still have to type:

    mutil hatch fsx_info c:\mystic\myfiles\file1.zip replace file1.zip
    mutil hatch fsx_info c:\mystic\myfiles\file2.zip replace file2.zip
    mutil hatch fsx_info c:\mystic\myfiles\file3.zip replace file3.zip
    mutil hatch fsx_info c:\mystic\myfiles\file4.zip replace file4.zip
    mutil hatch fsx_info c:\mystic\myfiles\file5.zip replace file5.zip

    I am not disagreeing that there should be a better way, just thinking out loud I guess about whether or not its really that much faster.

    The TIC workaround you're already doing is very clever, and I am wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound and create a .TIC for it, then MUTIL will import it to you BBS and toss it to the downlinks.

    So I'd like to ask for an option one also- Mystic to upload to the base and hatch. But this should be something separate from what we're brainstorming as a AutoHatch function in MUTIL.

    Okay so we could have AutoHatch in MUTIL only work if the file exists, but then a separate command line option that would copy it into the file base, upload it, and then hatch it (or if the file exists, it'd just update the existing record and still hatch it). Sounds reasonable to me!

    I'm wondering perhaps it can be something added to the MassUpload
    function so there's a hatch switch?

    Maybe it could even be a flag on a file base "Auto hatch" which automatically hatches any new files that are mass uploaded into that base. But it would not hatch files that are uploaded into the base by a BBS user.

    I do worry a little bit that someone could accidentally toggle the flag ON and end up hatching a bunch of files out somewhere. Even if it seems far fetched people really do seem to sometimes find ways to do some far fetched things :)

    Well I think now we have even more possible options on the table with all of this discussion haha! I am not sure which approach to take. Out of all of these ideas which do you think would be the most useful combination of
    options for you?

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Black Panther@21:1/186 to g00r00 on Friday, February 01, 2019 17:06:21
    On 01 Feb 2019, g00r00 said the following...

    My thoughts are that if you're going to hatch a file it should require
    it to actually be in the file listing for that file echo otherwise you
    can hatch files out that don't even exists in the hub's file base.

    I know this was Paul's suggestion to add, but I'm gonna jump in and give my 2 cents. :)

    I would think, it would be easy enough to have the file imported into
    Mystic's filebase, and then hatch it from there. It would just be a matter of having separate events to complete the process.

    Again, just my 2 cents... :)


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A42 2019/01/31 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Black Panther@21:1/186 to Avon on Friday, February 01, 2019 17:21:01
    On 02 Feb 2019, Avon said the following...

    I opted to follow the process of finding a new file, dropping it in to fsx_utls file directory on the local HDD, logging into the HUB, and running the mass upload option from the file menu for the fsx_utils base.

    Hi Paul,

    Wouldn't it be easier to just use the mutil.ini stanza [MassUpload]?

    Perhaps if something could be added to that stanza, which allows imported
    files to be auto hatched...

    snip<=-

    [MassUpload]

    uploader_name = fsxNet's Mystic Guy
    import_fileid = 1
    no_description = No Description
    ignore = files.bbs

    ; List of files to hatch automatically when executed
    ; Format: Area ID or echotag, filename, replaces filename (optional
    ; All fields are separated by a pipe character |

    file = fsx_info | fsxinfo.zip | fsxinfo.zip
    file = fsx_node | fsxnode.zip | fsxnode.zip

    snip<=-

    Just a thought, as I play devil's advocate... :)


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A42 2019/01/31 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Andrew Leary@21:4/105 to g00r00 on Friday, February 01, 2019 19:15:27
    Hello g00r00!

    01 Feb 19 15:46, you wrote to Avon:

    The TIC workaround you're already doing is very clever, and I am
    wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound
    and create a .TIC for it, then MUTIL will import it to you BBS and
    toss it to the downlinks.

    This is how hatching works in MBSE. The hatch script creates a .tic in the inbound, which mbfido processes to add the file to the BBS filebase and forward it to any downlinks.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)
  • From Avon@21:1/101 to Black Panther on Saturday, February 02, 2019 23:06:55
    On 01 Feb 2019 at 04:21p, Black Panther pondered and said...

    Wouldn't it be easier to just use the mutil.ini stanza [MassUpload]?

    Perhaps if something could be added to that stanza, which allows imported files to be auto hatched...

    I think you'll find I suggested that as one option in my original reply :) So yeah, great minds thinking alike.

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Saturday, February 02, 2019 23:09:49
    On 01 Feb 2019 at 03:46p, g00r00 pondered and said...

    This is my process for hatching a bunch of brand new files now:

    It's got late here and my brain is fried for the night, so will read this one more closely tomorrow and reply then :)

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Saturday, February 02, 2019 23:25:37
    On 01 Feb 2019 at 06:50a, g00r00 pondered and said...

    rather sit on hold until the node polls... some setting lik autohold if file size > x Kb

    I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enabl now and it will be in the next build but probably still untested

    Heh good to know I'm not the only one pondering this. :)

    Nope this was all your idea! You had mentioned it to me some time ago
    and I thought it was a great idea, so you get all the credit! :)

    [snip]

    + New option for each Echomail node: Crash Limiter. When FidoPoll sends
    files via BINKP it will skip queueing any files for sending larger than
    this value. The value is defined in kilobytes.

    [snip]

    Thank you for adding this. As we both probably realise adding this setting
    for 50+ nodes without a global echonode editor will take some time. So what I thought of was this.

    Do you think you could add a Crash Limiter global setting somewhere? Perhaps
    it would be most appropriate in the Configuration > General Settings section

    The idea being a sysop could set this value here and it would apply to all echonodes that had no setting applied (echonode value = 0) and if the sysop wanted to override this s/he could just set a specific value for a given echonode that would override the global setting. If the global setting was
    also set to 0 then no global action would be applied to all echonodes.

    Just a thought..

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Monday, February 04, 2019 14:15:57
    On 01 Feb 2019 at 03:46p, g00r00 pondered and said...

    This is my process for hatching a bunch of brand new files now:

    highlighted. Press E to edit, then select hatch press ] to go to the
    next file, then select hatch, ] hatch ] hatch. It should only take
    about a minute or two to hatch those files.

    From a command line you'll still have to type:
    mutil hatch fsx_info c:\mystic\myfiles\file1.zip replace file1.zip
    mutil hatch fsx_info c:\mystic\myfiles\file2.zip replace file2.zip

    I am not disagreeing that there should be a better way, just thinking
    out loud I guess about whether or not its really that much faster.

    I think it's more a case of how can things be run from a batch file or
    command line or similar and not having to do this from within a logged in
    state within Mystic. The non-logged in option(s) - whatever we come up with -
    I think will speed up the process and be useful, certainly from a HUB operations POV :)

    The TIC workaround you're already doing is very clever, and I am
    wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound
    and create a .TIC for it, then MUTIL will import it to you BBS and toss
    it to the downlinks.

    Works for me, so long as Mystic can tell it's a valid TIC etc. as at present
    to do this trick I have to create an echonode record for the system sending
    in the TIC.

    So I'd like to ask for an option one also- Mystic to upload to the ba and hatch. But this should be something separate from what we're brainstorming as a AutoHatch function in MUTIL.

    Okay so we could have AutoHatch in MUTIL only work if the file exists,
    but then a separate command line option that would copy it into the file base, upload it, and then hatch it (or if the file exists, it'd just update the existing record and still hatch it). Sounds reasonable to me!

    Yes exactly.

    I'm wondering perhaps it can be something added to the MassUpload function so there's a hatch switch?

    Maybe it could even be a flag on a file base "Auto hatch" which automatically hatches any new files that are mass uploaded into that
    base. But it would not hatch files that are uploaded into the base by a BBS user.

    I do worry a little bit that someone could accidentally toggle the flag
    ON and end up hatching a bunch of files out somewhere. Even if it seems far fetched people really do seem to sometimes find ways to do some far fetched things :)

    Yes I agree with the worry... and I am not sure about the mass upload options being discussed as a good idea or not, for the same concerns. I think the earlier command line option that will upload and hatch in one smooth sequence speaks to the same feature being kicked around for [massupload] so perhaps
    best to start with that and then refine things from there is there is a need
    or something else that becomes apparent?

    Well I think now we have even more possible options on the table with
    all of this discussion haha! I am not sure which approach to take. Out of all of these ideas which do you think would be the most useful combination of options for you?

    For hatching new files I like the idea of a command line that will create a
    TIC and set up Mystic to import the file into the file base and at the same time hatch it out to nodes connected to the file base. So essentially what I
    am doing now.

    For re-hatching files already in situ in a Mystic file base(s) I like what we have been discussing about a function in MUTIL that enables the sysop to
    state file bases and file names etc. to re-hatch and MUTIL works through the states list and does the business.. that would enable me to be able to resend files out to nodes from time to time and new nodes would then get them while older nodes would just ensure they had the latest copy of a file.

    I can't recall with the MUTIL re-hatch stanza if you were looking to make a provision for an external TXT file to be able to be stipulated as the source list of files to be re-hatched? But if you could include it as an option that would be helpful too.

    [related question]

    Do you know if there is a TIC verb that would allow a HUB to issue a remove command. So if a hatched file wanted to be recalled and removed from nodes it has been sent to, that the HUB could send a TIC to a node and instead of replacing a file, it would delete it instead?

    There are occasions where I have hatched files using a certain naming schema (supplied by the file author) then later on a new version is supplied but with a different naming schema, making replacing older files trickier if I miss
    this fact out when hatching stuff.

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Monday, February 04, 2019 10:53:11
    Works for me, so long as Mystic can tell it's a valid TIC etc. as at present to do this trick I have to create an echonode record for the system sending in the TIC.

    Yeah good point! I haven't really looked at the code to see how that would behave but it may not be worth the effort of changing the TIC processor to allow it.

    I am leaning more towards having it do the import and hatch itself, and then the next time the file tosser runs it will toss it. So it'd be a "real" hatch not a kludge using a .TIC.

    I can't recall with the MUTIL re-hatch stanza if you were looking to
    make a provision for an external TXT file to be able to be stipulated as the source list of files to be re-hatched? But if you could include it
    as an option that would be helpful too.

    You did mention this but to be honest I probably wasn't going to do it. Do you already have a list of files somewhere that you don't want to put into the AutoHatch stanza? I just want to get a feel of how you'd use it and the benefit of it being in an external file instead of having it defined in the stanza itself. I was planning just to do it like:

    [AutoHatch]
    file=fsx_info|fsxinfo.zip|fsxinfo.zip

    The first column would be the ID or echotag, the second would be the location and filename, the third would be optional "replace"

    --- Mystic BBS v1.12 A42 2019/02/01 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Tuesday, February 05, 2019 20:12:20
    On 04 Feb 2019 at 09:53a, g00r00 pondered and said...

    I am leaning more towards having it do the import and hatch itself, and then the next time the file tosser runs it will toss it. So it'd be a "real" hatch not a kludge using a .TIC.

    I agree

    I can't recall with the MUTIL re-hatch stanza if you were looking to make a provision for an external TXT file to be able to be stipulated the source list of files to be re-hatched? But if you could include i as an option that would be helpful too.

    You did mention this but to be honest I probably wasn't going to do it.
    Do you already have a list of files somewhere that you don't want to put into the AutoHatch stanza? I just want to get a feel of how you'd use
    it and the benefit of it being in an external file instead of having it defined in the stanza itself. I was planning just to do it like:

    Upon reflection I'd say just go with what you're thinking there is no real
    need for an external file to point to in this case. Loading things into an
    .ini file will do just fine :)

    Best, Paul

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

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)