Hi Andrew,

Got another one for you.

I've noticed that I receive tic files from non MBSE BBS's (Mystic at the moment), and those tic files have a name similar to the file they are representing. EG: pinet.tic for pinet.250, fsxinfo.tic for fsxinfo.zip.

MBSE is not processing those tic files - however if I renamed the tic file to have 8 numbers (with .tic) at the end, they were processed. EG: I renamed pinet.tic to 00000000.tic and it was processed.

I had a quick look at FTSC specs (5006.001 and 1039.001), and it doesnt
mention anything about how a tic file should be named (character limit nor
only numerical/hex chars, etc).

I then had a quick look at the code mbfido/tic.c and it looks like it will
only process a tic file if it has a length of 12 chars (being 8 chars plus ".tic"). Could this be changed? Or is it referenced somewhere else that tic files should be 8 chars (suffixed with .tic) and other BBS software is not following that standard?

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

Hello Deon!

12 Sep 18 13:54, you wrote to me:

I've noticed that I receive tic files from non MBSE BBS's (Mystic at
the moment), and those tic files have a name similar to the file they
are representing. EG: pinet.tic for pinet.250, fsxinfo.tic for fsxinfo.zip.

Yes, I've noticed the same thing.

MBSE is not processing those tic files - however if I renamed the tic
file to have 8 numbers (with .tic) at the end, they were processed.
EG: I renamed pinet.tic to 00000000.tic and it was processed.

I do the same thing with them when I find them in my inbound.

I had a quick look at FTSC specs (5006.001 and 1039.001), and it
doesnt mention anything about how a tic file should be named
(character limit nor only numerical/hex chars, etc).

FTS-5006.001 specifies a filename in DOS 8.3 format. Thus, it could be interpreted that .TIC files with shorter or longer names are non-compliant.

I then had a quick look at the code mbfido/tic.c and it looks like it
will only process a tic file if it has a length of 12 chars (being 8
chars plus ".tic"). Could this be changed? Or is it referenced
somewhere else that tic files should be 8 chars (suffixed with .tic)
and other BBS software is not following that standard?

In my mind, I consider Mystic's implementation to be non-compliant, although it probably should be clarified in the FTSC documentation as well.

When James Coyle comes back to working on Mystic again, I intend to mention this to him and see about getting it fixed.

If there appears to be a delay on this, I may add a switch to mbfido to enable processing of these "extended" .TIC names. MBSE will never create .TIC files with other than a DOS 8.3 style name ending in .TIC.

Regards,

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

On 09/12/18, Andrew Leary said the following...

FTS-5006.001 specifies a filename in DOS 8.3 format. Thus, it could be interpreted that .TIC files with shorter or longer names are non-compliant.

It could? I went to wikipedia to see what it has on 8.3 and it says this:

"8.3 filenames are limited to at most eight characters (after any directory specifier), followed optionally by a filename extension consisting of a
period . and at most three further characters."

The key words there are "at most" - which would imply they can be shorter?

Is there somewhere else that mentions that they should be 8 chars.

Perhaps MBSE could use the incoming tic name transiently, and actually
discard the pre .tic component and save it as $(mbseq).tic when it has been finally received? Then it wont matter how other systems present a tic file,
and it could avoid a clash (not sure if this part is ever an issue...)?

Just ideas...

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

Hey Andrew,

So this was bugging me - so I made a quick workaround.

--- a/mbfido/tic.c
+++ b/mbfido/tic.c
@@ -116,7 +116,9 @@

rewinddir(dp);
while ((de = readdir(dp))) {
- if ((strlen(de->d_name) == 12) && (strncasecmp(de->d_name+8, ".tic",
4) == 0)) {
+ Syslog('?', "Found file %s", de->d_name);
+ if ((strlen(de->d_name) >= 5) && (strlen(de->d_name) <= 12) && (strncasecmp(de->d_name+strlen(de->d_name)-4, ".tic", 4) == 0)) {
+ Syslog('?', "Added file %s", de->d_name);
stat(de->d_name, &sbuf);
fill_fdlist(&fdl, de->d_name, sbuf.st_mtime);
}

I know if the standard is that a tic file needs to be 12 chars in length (I think it would be good if it was - but I'm not sure that that is the
standard), then it would be good if on a node by node (or global config?)
that you can "override" the standard. "Allow Non Standard TIC [YES|NO]"

What do you think?

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

Hello Deon!

17 Sep 2018 00:03, Deon George wrote to Andrew Leary:

I know if the standard is that a tic file needs to be 12 chars in
length (I think it would be good if it was - but I'm not sure that that is

the

standard), then it would be good if on a node by node (or global
config?)

its msdos formated, we would not break it, even amiga and linux, windows 10 now
support long filenames, it does not mean we would enabled it

that you can "override" the standard. "Allow Non Standard TIC
[YES|NO]"

What do you think?

breaks msdos :)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.1.2 (Linux/4.18.8-gentoo (x86_64))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Deon!

17 Sep 18 00:03, you wrote to me:

So this was bugging me - so I made a quick workaround.

I am testing a fix for this problem now. I also am allowing it to handle incoming .TICs with long filenames (over 8 characters for the filename portion.) Mystic creates these when hatching a file with a long filename.

I know if the standard is that a tic file needs to be 12 chars in
length (I think it would be good if it was - but I'm not sure that
that is the standard), then it would be good if on a node by node (or global config?) that you can "override" the standard. "Allow Non
Standard TIC [YES|NO]"

The intention when the standard was written was to specify a DOS compatible 8.3 filename for .TIC files. At the time, all known implementations did it that way.

What do you think?

I don't see the need to enable or disable this on a per-node basis. Since MBSE will never create these non-compliant .TIC files, it just needs to handle them properly when receiving them.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

On 09/17/18, Benny Pedersen said the following...

its msdos formated, we would not break it, even amiga and linux, windows 10 now support long filenames, it does not mean we would enabled it

What do you think?

breaks msdos :)

I dont understand. My patch is to fix .TIC filenames that are < 12 chars in size. (And at least 5 chars in size including the suffix .TIC).

My DOS is rusty, but that doesnt seem to break it?

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

On 09/17/18, Andrew Leary said the following...

I don't see the need to enable or disable this on a per-node basis.
Since MBSE will never create these non-compliant .TIC files, it just
needs to handle them properly when receiving them.

Understood - the fix is for those upstream (or downstream?) that dont create
12 char TIC files.

But if you are testing a fix something that will address that scenario,
awesome :)

...deon

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Chinwag | MysticBBS in Docker! (3:633/509.1)

Hello Deon!

17 Sep 2018 10:33, Deon George wrote to Benny Pedersen:

I dont understand. My patch is to fix .TIC filenames that are < 12
chars in size. (And at least 5 chars in size including the suffix .TIC).

ah my bad, msdos does not forbid to use less then 8.3 format

My DOS is rusty, but that doesnt seem to break it?

keep it max as 8 chars for filename, and 3 chars for extension


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.1.2 (Linux/4.18.8-gentoo (x86_64))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Benny!

17 Sep 18 07:22, you wrote to Deon George:

its msdos formated, we would not break it, even amiga and linux,
windows 10 now support long filenames, it does not mean we would
enabled it

breaks msdos :)

Mystic already is using non-compliant filenames; the fix I've committed to Hg and Git today just allows MBSE to find and process them. MBSE sends DOS compatible 8.3 filenames for all .TIC files.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)