On 12/09/17, Avon said the following...

Do you mind posting your snippets of the .ini file here or in FSX_MYS and let's see if we can suss why? :)

Sure thing.
So when I received FSX_ARTS and FSX_MUTL from Todd for the first time, mutil correctly set list, ftp, download, upload and sysop ACS to s255z2 as per the configuration. The hatch ACS alone was set up as s255z1 instead, and the
bases were created directly under /opt/mystic/files/ instead of /opt/mystic/files/fsx/

The log reported nothing out of the ordinary, just that it received files
from 21:2/100 and created the bases to add the files to them.

Here's the .ini:
[General]
FileToss = true

logfile=filetoss.log
loglevel=2
logtype = 0
maxlogfiles = 3
maxlogsize = 1000

[FileToss]
bad_dir=/opt/mystic/files/badfile/
unsecure_dir = true
no_desc=No Description
uploader=Network
check_crc = true
check_size = true
allow_unsecure = false
allow_replace = false
auto_create = true
dir_prefix = /opt/mystic/files/

; auto_create defaults
dispfile =
template = ansiflst
acs_list = s10z1
acs_ftp = s255z1
acs_download = s20z1
acs_upload = s255z1
acs_hatch = s255z1
acs_sysop = s255z1

free_files = 1
show_uploader = 1
new_scan = 1

; auto_create fsxnet
21:2/100_bad_dir = /opt/mystic/files/fsx/badfile/
21:2/100_dir_prefix = /opt/mystic/files/fsx/
21:2/100_allow_replace = true
21:2/100_acs_list = s255z2
21:2/100_acs_ftp = s255z2
21:2/100_acs_download = s255z2
21:2/100_acs_upload = s255z2
21:2/100_acs_hatch = s255z2
21:2/100_acs_sysop = s255z2

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 12/09/17, Static pondered and said...

On 12/09/17, Avon said the following...

Do you mind posting your snippets of the .ini file here or in FSX_MYS let's see if we can suss why? :)

Sure thing.
So when I received FSX_ARTS and FSX_MUTL from Todd for the first time, mutil correctly set list, ftp, download, upload and sysop ACS to s255z2
as per the configuration. The hatch ACS alone was set up as s255z1 instead, and the bases were created directly under /opt/mystic/files/ instead of /opt/mystic/files/fsx/

Nothing you have shared looks amiss to me. I wonder if because the ACS hatch stuff is still a work in progress for g00r00, if that might be behind why the network (in this case fsxNet) specific ACS settings were not carried across?

The stranger one for me is why the directory prefix settings for 21:2/100
were not honored?

; auto_create fsxnet
21:2/100_bad_dir = /opt/mystic/files/fsx/badfile/
21:2/100_dir_prefix = /opt/mystic/files/fsx/
21:2/100_allow_replace = true
21:2/100_acs_list = s255z2
21:2/100_acs_ftp = s255z2
21:2/100_acs_download = s255z2
21:2/100_acs_upload = s255z2
21:2/100_acs_hatch = s255z2
21:2/100_acs_sysop = s255z2

I take it you had a /opt/mystic/files/fsx/ dir in place before all this happened? And the same for /opt/mystic/files/fsx/badfile ?

g00r00 may wish to comment also.

Best, Paul

--- Mystic BBS v1.12 A37 2017/12/07 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 12/10/17, Avon said the following...

Nothing you have shared looks amiss to me. I wonder if because the ACS hatch stuff is still a work in progress for g00r00, if that might be behind why the network (in this case fsxNet) specific ACS settings were not carried across?

If mutil isn't actually looking for per-node acs_hatch directives that would certainly explain that.

The stranger one for me is why the directory prefix settings for 21:2/100 were not honored?
I take it you had a /opt/mystic/files/fsx/ dir in place before all this happened? And the same for /opt/mystic/files/fsx/badfile ?

Yes, the fsx and badfile directories were already in place. It's like mutil just didn't see the dir_prefix line for fsx node in the .ini at all.
It's possible the badfile directive might have the same issue but I've yet to receive a bad file that would test it.

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

I take it you had a /opt/mystic/files/fsx/ dir in place before all this happened? And the same for /opt/mystic/files/fsx/badfile ?

g00r00 may wish to comment also.

If the configuration is wrong I think it will be processed as unsecure which explains where the hatched ACS gets sourced from. This is my guess.

Notice here in the example, its used to add a prefix not to specify a directory while the configuration he is using specifies a directory, not a prefix.

I don't think I intended it to be used the way he wants it to be used (ie, to create a directory tree type structure based on network) but maybe this is something that could be updated.

; The directory prefix for auto-created bases. This will be used with the
; areatag appended onto it, so for example if prefix was set to:
;
; dir_prefix=c:\bbs\files\fdn_
;
; And the areatag was "nodelist", Mystic would create and the use path:
; c:\bbs\files\fdn_nodelist\
;
; And the datafile would be fdn_nodelist

dir_prefix = d:\mystic\files\fdn_

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/09/17, g00r00 pondered and said...

Notice here in the example, its used to add a prefix not to specify a directory while the configuration he is using specifies a directory, not
a prefix.

Ah, yes good point.

I don't think I intended it to be used the way he wants it to be used
(ie, to create a directory tree type structure based on network) but
maybe this is something that could be updated.

I think this is a good idea. That said, I also think if a directory such as

bad_dir=d:\mystic\files\badfile

is specified in the .ini then perhaps a switch (somewhere) to allow Mystic to auto create those dirs as well.

I have seen issues before when helping others whereby they have not picked up error messages in MUTIL that say things like 'error - missing bad directory'
so I'm wondering if you do allow MUTIL to auto create directories when processing incoming files, then perhaps let it auto create key system directories too?

Or perhaps some of those key system directories should move from MUTIL ini to Mystic -cfg ?

--- Mystic BBS v1.12 A37 2017/12/07 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 12/09/17, g00r00 said the following...

If the configuration is wrong I think it will be processed as unsecure which explains where the hatched ACS gets sourced from. This is my
guess.

By wrong configuration are you referring specifically to using a directory as
a prefix? I'm still not sure why only the hatch ACS is affected.

I don't think I intended it to be used the way he wants it to be used
(ie, to create a directory tree type structure based on network) but
maybe this is something that could be updated.

Something like root_dir in the filebone import stanza? They could potentially even be combined, eg:
21:2/100_root_dir = /opt/mystic/files/fsx/
21:2/100_dir_prefix = fdn_

On a side note the example in the mutil.ini uses the flag 'g' for file group access control, which doesn't appear to work and needed to be changed to 'z'.

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

I think this is a good idea. That said, I also think if a directory such as

bad_dir=d:\mystic\files\badfile

is specified in the .ini then perhaps a switch (somewhere) to allow
Mystic to auto create those dirs as well.

The reason they aren't auto created is because those values are just default values that show up in EVERY default mutil.ini. Unless everyone used Windows and installed Mystic to "D:\MYSTIC" then auto creating that default above wouldn't work.

The installation program would need to create/update the INI based on the operating system and installation location for the defaults to have any sort
of meaningful value.

Or we'd have to move over to the relative path directory structure that the Mystic2demo uses (push push hint hint!).

For now, people will just have to not ignore the red "FATAL ERROR" text in MUTIL when they run it, or they'll have to read the logs. :)

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/09/17, g00r00 pondered and said...

bad_dir=d:\mystic\files\badfile

is specified in the .ini then perhaps a switch (somewhere) to allow Mystic to auto create those dirs as well.

The reason they aren't auto created is because those values are just default values that show up in EVERY default mutil.ini. Unless everyone

[snip]

For now, people will just have to not ignore the red "FATAL ERROR" text
in MUTIL when they run it, or they'll have to read the logs. :)

Fair enough...

Or we'd have to move over to the relative path directory structure that the Mystic2demo uses (push push hint hint!).

:)

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On a side note the example in the mutil.ini uses the flag 'g' for file group access control, which doesn't appear to work and needed to be changed to 'z'.

FYI: The groups don't have to be specific to message or file bases, they're just two sets of groups that you can use anywhere. Some people choose to use only one set of groups and separate things out by Network.

In my case I have a FidoNet group which contains Fido message bases and file areas, FSX which contains FSX message bases and file areas, etc. They all
use "g".

I'll update the default though to show Z there, thanks for the heads up!

--- Mystic BBS v1.12 A37 2017/12/10 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)