Re: Re: Problem with filenames containing spaces
By: James Coyle to Oli on Tue Jan 18 2022 03:50 pm

James,

And its sad that you convinced non-FTN-techincal people like Paul and Deon that you are some sort of subject matter expert (when everyone who actually does this stuff knows you're a subject matter idiot).

So I'll have to disagree with you there.

What makes you think I am "non-FTN-technical"?

What makes you think that I have pondered whether Oli is a "subject matter expert"? Now that you mention it though, his research and understanding of the problem is spot on IMHO.

We've had this kind of discussion before - I dont think you understand the problem - mainly because your replies conflict. I'm still not convinced that the problem is with Binkd (actually I'm very confident it is not), but that is moot - if your software doesnt work with it, I dont get why you wouldnt want to make it work with it, even if the binkd development team werent interested in "fixing" it the way you want it "fixed".

You have many people that like your software, wouldnt you want to make it work so that they dont have a reason to look for something else (if it's failures were becoming problematic for them)?

You have a known use case, as from the logs received by a Mystic user, the file "MyGUI v1.0.2.26.zip" is encoded as "MyGUI\x20v1.0.2.26.zip" by binkd and sent to a Mystic system. Mystic recorded "BINKP 1-Receiving: MyGUI\000v1.0.2.26.zip (1,669,424 bytes)" in the log file, and saved the received portion as "MyGUI" (instead of it's proper name - I'm guessing related to the \00?). The M_GOT response only included the text "M_GOT MyGUI", not what it should have quoted back "M_GOT MyGUI\x20v1.0.2.26.zip 1669424 1641463672", hence binkd bawlked with an error and kept re-trying to send the file everytime the node connected.

Anyway, I dont use it - we know it cannot handle files with spaces in it from a binkd mailer.


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Anyway, I dont use it - we know it cannot handle files with spaces in it from a binkd mailer.

Ergo: stay away from FTN software that demonstrably will never change when pointed out errors.

After all, there's a plethora of alternatives, many of them Open Source (like the product discussed in this echo), so why insist on using something that you can see never will fix obvious bugs?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

is not), but that is moot - if your software doesnt work with it, I dont get why you wouldnt want to make it work with it, even if the binkd development team werent interested in "fixing" it the way you want it "fixed".

My software works fine with it, there is nothing I could possibly change. It handles all formats of escaping and its configurable per node. The person in this case is using a version many years old with a bug, but you knew that.

You know it because I have explained this to you now in three different messages, and you keep ignoring it. I don't want anything fixed. I never posted here asking for anything, someone else did. I could care less if BINKD adds it or not but given its a FTS guideline I think it should. I keep telling you that but again, you just ignore it.

You should ask yourself the same question you just asked me: If implementing the *FTS recommendations for handling filename escaping* into BINKD would make it work better with more mailers, then why not do it? Wouldn't you want to make it better? BINKD will fail with any legacy mailer that uses the \XX format and those legacy mailers cannot be updated only BINKD can.

To answer your "would you want to fix it" question. When this issue was brought to me back in 2020 I made changes within an hour of reporting it, and the person who did so didn't have to push through all this drama and resistance for no reason. So yes, as my reputation fully has proven over more than two decades, I respond very quickly and fix issues often times in the same day its reported. You can go back 20 years and see this very thing happen over and over again.

Its really weird how you guys go on and on about FTS compliance and then you ignore whats going on and cherry pick what should and shouldn't be applied when it aligns with whatever narrative you're trying to push.

... Message encrypted: Press ALT-F4 to read encoded message

--- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Anyway, I dont use it - we know it cannot handle files with spaces in BF> d> BF> d> BF> d> BF> d>
from a binkd mailer.

After all, there's a plethora of alternatives, many of them Open
Source (like the product discussed in this echo), so why insist on using something that you can see never will fix obvious bugs?

Agreed. Why would anyone use the software that is outright refusing to implement FTS guidelines for filename escaping? One that would knowingly fix compatibility issues with legacy BINKP implementations?

It took a whole hour to get this implemented when it was asked to be added into Mystic and the person who asked didn't have to endure a bunch of drama!

Other options are right :)

... Running Windows is better than washing them!

--- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

James Coyle -> Bj”rn Felten skrev 2022-01-19 05:32:

Anyway, I dont use it - we know it cannot handle files with

spaces in BF> d> BF> d> BF> d> BF> d>

from a binkd mailer.

And if the above total mangling of the comments isn't enough to convince you, please stay shy of this inferior product.






..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

James wrote (2022-01-18):

is not), but that is moot - if your software doesnt work with it, I
dont get why you wouldnt want to make it work with it, even if the
binkd development team werent interested in "fixing" it the way you
want it "fixed".

My software works fine with it, there is nothing I could possibly change.
It handles all formats of escaping and its configurable per node.

"Configurable per node" was maybe a decent idea when the binkp FTS was written*. Today it's an unnecessary configuration option, bad UX, additional noise and an opportunity for misconfiguration. We know the few mailers that cannot cope with the standard \x##. I believe they all send the M_NUL VER command. Why not auto-detect the broken mailer and switch to the incorrect escape \## automatically?

Per node configuration does not work for all use cases. Let's not forget that there is a nodelist and we can connect to most nodes directly without the need to explicitly configure anything for that node. The nodelist also does not tell me, which software is answering the connection. Per node configuration is a flawed and ugly workaround.

Is there any other mailer than Argus and Irex that doesn't understand \x##?


* I believe the inclusion of \## in FTS-1026 was more harmful than it did any good in the long term.

* Origin: Birds aren't real (2:280/464.47)

On 2022 Jan 18 15:50:58, you wrote to Oli:

I covered this in every response to you, but you don't seem to care.
So instead I'll tell a story because I know he was reading this
thread:

/me waves from across the network :)

[...]

To this day, Mystic might be the only software I've seen working
across the board (net/echo) with same-zone different-domain networks
in 5D.

i have sbbsecho and binkd working here with FTN 5D BSO where each different network has its own outbound... even the 18 or so othernets that share 8 zones, i think, between them... my outbound directory has like 83 or so different outbounds in it... not that all of those networks are active or that my system is a member of them :)

i haven't tried sbbs' binkit mailer in a while but it should work just fine in this setup... i think i initially set it up with binkit and then switch to binkd to confirm it was right :)

It came at the cost of Marc and bickering and maybe ruining our own collaboration, but at least the software works. :(

i hate that we had our falling out and i'm sorry that it ever happened... it is in the past, though, and i/we have moved on :)

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Make millions: Start a restaurant called No Stupid Birthday Songs.
---
* Origin: (1:3634/12.73)

On 2022 Jan 19 13:48:08, you wrote to All:

Is there any other mailer than Argus and Irex that doesn't understand \x##?

radius and taurus are from the argus family... or is it argus and taurus that are from the radius family? i always get the first two confused... i'm not even sure which ones of that family are still being updated today... i just thought i'd mention them since they may have the same defect in them...

IIRC, there is also at least one other mailer derived from that family but i don't recall what it is named or even what OS it is for... it, too, may also have this defect... idk...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... A lobster is a crawfish on steroids.
---
* Origin: (1:3634/12.73)

few mailers that cannot cope with the standard \x##. I believe they all send the M_NUL VER command. Why not auto-detect the broken mailer and switch to the incorrect escape \## automatically?

Yes that would be a good solution maybe a little more challenging to implement, but thats a good idea too!

Unfortunetly those legacy mailers are out there although less and less these days. People can upgrade to a newer version of Mystic if they are running and old release so that should be fine. But some people (believe it or not) still use Argus and especially like IREX. My Fido hub is using an IREX version from like 1999 to this day.

Is there any other mailer than Argus and Irex that doesn't understand \x##?

The only thing I know of is Argus and some if its clones, versions of IREX, and older Mystic versions. I do remember testing against some Argus spin offs that actually did update to support \x## so its not all of them. Some were updated.

My findings were three types of escaping:

1) Those that escape with \## exclusively and work with nothing else
Argus, IREX, older versions of Mystic

2) Those that escape with \x## but still allow \## from the mailer side
BinkD (I think MBSE does too)

3) Those that escape with \x## and only work with \x## disallowing \##
Some Argus spin-offs like Radius, Synchronet's BinkIT, maybe others?

I don't know where BBBS fits in.

Both MBSE and newer Mystic provides the option to support \## or \x## escaping per connection as noted. This seems to be what FTS recommends as a way to handle this mess. It does seem to be a viable solution but your idea is great too!

* I believe the inclusion of \## in FTS-1026 was more harmful than it
did any good in the long term.

Yeah its very confusing.

Another confusing thing (and is partially responsible for how Mystic got it wrong originally) is that when you look up BinkP on Wikipedia it links to the old specifications released by the authors of Argus. If I remember correctly it was really difficult to even find FTS documentation when I was first implementing FTN into Mystic so these kind of links proved to be a pain point.

My testbed was Argus, IREX, and BinkD and \## was the only thing that worked with all of them as I recall, and it matches what Wikipedia says so thats what Mystic used back then...

Unfortunately that is wrong as I later found Radius mailers that only supported \x## and I believe BinkIT falls into this category as well.

I think in hindsight it might have been better for FTS to leave it as \## since legacy mailers used it and could not be updated, but it is what it is!

Thank you for the kind and constructive response :)

... Honk if you love peace and quiet!

--- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

mark wrote (2022-01-19):

On 2022 Jan 19 13:48:08, you wrote to All:

Is there any other mailer than Argus and Irex that doesn't
understand \x##?

radius and taurus are from the argus family... or is it argus and taurus that are from the radius family? i always get the first two confused...

One big happy family ;).

https://github.com/oldprogs/taurus/blob/5ab0e09ad2bdc43bd5dae10bf9aa2ef03b21572b/src/xBase.pas#L55

CProductNameFull = 'Taurus (based on Radius (based on Argus))'

And the versions are:
Argus 3.210
Radius 4.011
Taurus 5.101

i'm not even sure which ones of that family are still being updated today...

AFAIK development has stopped for all three some time ago.

i just thought i'd mention them since they may have the same
defect in them...

I believe Radius and Taurus have fixed the problem:

https://github.com/maximmasiutin/argus/blob/c8b06f333facdf9f2d5f28feb048f7aa78c3513a/SRC/xBase.pas#L5758
https://github.com/oldprogs/radius/blob/6eb804993455f9151768253953727b0dbf71fe73/beta/src/xBase.pas#L6511
https://github.com/oldprogs/taurus/blob/5ab0e09ad2bdc43bd5dae10bf9aa2ef03b21572b/src/xBase.pas#L6167

Argus:
Result := PackStrEx(s, ' ', '\');
Result := UnpackStrEx(s, '\');

Radius & Taurus:
Result := PackStrEx(s, [#0..#255] - charset, '\x');
Result := UnpackStrEx(s, '\x');

Anyone still using Argus should upgrade to Radius or Taurus. (I haven't used any of the programs, so I don't know if it's an easy upgrade and would work for everyone).

---
* Origin: Birds aren't real (2:280/464.47)

And if the above total mangling of the comments isn't enough to convince you, please stay shy of this inferior product.

You are free to download and reproduce whatever issue it is you're claiming Mystic has and report it. But lets face it, you haven't used it and you have no idea what you're talking about (shocker).

Your software also spits out endless amounts of CRs and whitespace in your text that looks like trash but who cares about that right?

..

It might be beneficial to keep this echo on topic though instead of behaving like a toddler for no reason.

--- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

/me waves from across the network :)

:)

i have sbbsecho and binkd working here with FTN 5D BSO where each different network has its own outbound... even the 18 or so othernets
that share 8 zones, i think, between them... my outbound directory has

Thats awesome you have quite the setup going! And its great to hear its working well for you!

happened... it is in the past, though, and i/we have moved on :)

Absolutely, never anything personal :)

... My tagline could eat your tagline for breakfast

--- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

On 2022 Jan 19 18:18:14, you wrote to me:

radius and taurus are from the argus family... or is it argus and
taurus that are from the radius family? i always get the first two
confused...

One big happy family ;).

yep...

CProductNameFull = 'Taurus (based on Radius (based on Argus))'

ahhh, yeah... i used to call it the ART-family of mailers... couldn't remember if it was ART or RAT earlier :lol:

i'm not even sure which ones of that family are still being updated
today...

AFAIK development has stopped for all three some time ago.

i used to follow them on sourceforge... at least, i used to follow someone on there that had the code to all of them... i had the code, at one time, too... was going to port it to freepascal but ran into a few problems and then real life kicked in and got in the way... i just haven't been back to try porting any of them again...

Anyone still using Argus should upgrade to Radius or Taurus. (I
haven't used any of the programs, so I don't know if it's an easy
upgrade and would work for everyone).

switching from one to another was just a matter of dropping the new binary in place... the config files were compatible, AIR... before my vista box shat the bed and ruined the sheets, i used to test all three of them on one of my point systems...

i was well into translating the russian chm help files to english, too... still had a way to go in them, though... ran into some translating problems with one site (it disappeared i think?) and had to switch to using another one... that meant doing one paragraph at the time instead of a whole page at the time... oh well...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... 32. When traveling, keep your wits about you.
---
* Origin: (1:3634/12.73)

additional noise and an opportunity for misconfiguration. We know the
few mailers that cannot cope with the standard \x##. I believe they all send the M_NUL VER command. Why not auto-detect the broken mailer and switch to the incorrect escape \## automatically?

I don't want to get too far off topic here so I will end with this and show what I ended up doing on the Mystic side to clarify for everyone here...

I agree with you about additional noise and misconfiguration - we seem to share a similar opinion on bloated configurations! But since I already had it as an option, I went back and added an "Auto" option based on your suggestion.

Auto will be the default moving forward. If you have any suggestions or feedback on this shoot me a netmail or in MYSTIC echo or something. I don't want to clutter up BINKD with Mystic stuff...

If BINKD wants to add something similar to help support legacy mailers then great, if not then so be it! :)

+ Mystic's BINKP server now has a default "Escape mode" option which will
apply to any unknown connections that do not have a configuration in the
Echomail nodes. Echomail nodes also have their own individual setting for this in the node editor.

This setting determines how Mystic will escape special characters in
filenames and defaults to the Auto setting.

When set to Auto, Mystic will automatically try to determine the escape
mode by using the VERSION frame sent by the mailer. If no version frame
is found, Mystic will use FTS standard modern \x## escape mode.

When set to Legacy, Mystic will use the \## format of file escaping which
is used in some legacy mailers such as Argus, Internet Rex, and older
versions of Mystic.

When set to Modern, Mystic will use the \x## format which is preferred or
even required by some newer mailers such as BinkD, Radius, and BinkIT.

... Computers are not intelligent. They only think they are.

--- Mystic BBS v1.12 A48 2022/01/19 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Hello James!

19 Jan 22 11:14, you wrote to Oli:

2) Those that escape with \x## but still allow \## from the mailer
side
BinkD (I think MBSE does too)

I just verified in the code that mbcico defaults to sending \x##, but can be overridden on a per node basis to send \##. Both will be accepted on the incoming side.

Both MBSE and newer Mystic provides the option to support \## or \x## escaping per connection as noted. This seems to be what FTS
recommends as a way to handle this mess. It does seem to be a viable solution but your idea is great too!

I would have to test further to populate the list of mailers that require setting the WrongEscape option (as it's labeled in the mbcico code.)

Another confusing thing (and is partially responsible for how Mystic
got it wrong originally) is that when you look up BinkP on Wikipedia
it links to the old specifications released by the authors of Argus.
If I remember correctly it was really difficult to even find FTS documentation when I was first implementing FTN into Mystic so these
kind of links proved to be a pain point.

This is the big reason that the FTSC created the ftsc.org website.

My testbed was Argus, IREX, and BinkD and \## was the only thing that worked with all of them as I recall, and it matches what Wikipedia
says so thats what Mystic used back then...

If you ever need clarification on anything related to the FTSC, please don't hesitate to netmail me.

Unfortunately that is wrong as I later found Radius mailers that only supported \x## and I believe BinkIT falls into this category as well.

I would have to test to be sure.

I think in hindsight it might have been better for FTS to leave it as
\## since legacy mailers used it and could not be updated, but it is
what it is!

BinkD (the original implementation of BinkP) has always used \x## as far as I know.

Andrew

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

Re: Problem with filenames containing spaces
By: Andrew Leary to James Coyle on Wed Jan 19 2022 08:52 pm

BinkD (the original implementation of BinkP) has always used \x## as far as I know.

BinkD was changed to *accept* '\##' however, back in 2002: https://github.com/pgul/binkd/commit/b4e7b17b7f0621abc1b3017307dd1382eaa039d9 --
digital man (rob)

Breaking Bad quote #47:
He said he'll break my legs, he meant It... he gave me the dead mackerel eyes. Norco, CA WX: 55.0øF, 83.0% humidity, 1 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob!

19 Jan 22 19:58, you wrote to me:

BinkD (the original implementation of BinkP) has always used \x##
as far as I know.

BinkD was changed to *accept* '\##' however, back in 2002: https://github.com/pgul/binkd/commit/b4e7b17b7f0621abc1b3017307dd1382e aa039d9

That explains why when James tested against BinkD it had no issues with him using \##.

The most compatible way to do things is to accept both on incoming, while sending using \x##, unless configured otherwise on a per node basis, or when you detect you are connected to a known mailer that uses \## (Argus or IRex.)

Andrew


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

Hi Andrew,

On 2022-01-19 20:52:19, you wrote to James Coyle:

If you ever need clarification on anything related to the FTSC, please don't hesitate to netmail me.

I tried that in the FTSC_PUBLIC area a month ago and a reminder in a crash netmail last monday, but no response yet. :-(

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Andrew wrote (2022-01-19):

I think in hindsight it might have been better for FTS to leave it
as \## since legacy mailers used it and could not be updated, but
it is what it is!

BinkD (the original implementation of BinkP) has always used \x## as far as I know.

That is my understanding too and that it is what I was trying to tell. Binkd always used \x## (according to older source codes). I believe \## was never meant to be a standard, but it was a small (but significant) mistake in the documentation (FSP-1011) of the protocol. Then some authors implemented that erroneous spec (which was still a proposal) in their mailers. For some reason 4 years passed until a new proposal by new authors (FSP-1018) was published by the FTSC and another 2 years until it became a standard (FTS-1026). Meanwhile, since 2004, the Wikipedia page on binkp [1] linked to the original FSP-1011 [2] until I edited the page yesterday and changed it to FTS-1026.

So it's not that every mailer used \## before FSP-1026 and then deprecated it and changed the escape sequence to \x##.

Fun fact: FSP-1011 was written by the author of Binkd (Dima Maloff) and the author of Argus (Maxim Masiutin). Binkd used \x## and Argus \##. If they were confused and unable to document the correct escape sequence, no wonder that others made the mistake too.

[1] https://en.wikipedia.org/wiki/Binkp
[2] https://www.ritlabs.com/binkp/

---
* Origin: Birds aren't real (2:280/464.47)

Andrew wrote (2022-01-20):

BinkD (the original implementation of BinkP) has always used \x##
as far as I know.

BinkD was changed to *accept* '\##' however, back in 2002:
https://github.com/pgul/binkd/commit/b4e7b17b7f0621abc1b3017307dd1382e
aa039d9

That explains why when James tested against BinkD it had no issues with him using \##.

And I think adding that workaround for broken mailers was a mistake that brought us more incompatibilities. Or should have been only a temporary workaround and deprecated a few years later.

https://en.wikipedia.org/wiki/Robustness_principle#Criticism https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance

The most compatible way to do things is to accept both on incoming, while sending using \x##, unless configured otherwise on a per node basis, or when you detect you are connected to a known mailer that uses \## (Argus or IRex.)

All the big drama for a single legacy mailer: Irex that hasn't been updated forever. Argus users can upgrade to Radius or Taurus (both abandonware). Mystic is actively developed and users should use the latest release.

Let's face it: closed source software that isn't developed anymore has to become obsolete in a communication network that evolves (even slowly). If you want to do it the old way, you can still use EMSI over TCP.

And it's only a problem with filenames that contains a whitespace character.

---
* Origin: Birds aren't real (2:280/464.47)

I would have to test further to populate the list of mailers that
require setting the WrongEscape option (as it's labeled in the mbcico code.)

I haven't finished fully testing it, but here is what I came up with as an automated way to use the \## mode based on Oli's suggestion to check the VER frame:

If the VER frame contains any of "Internet Rex", "Argus" or "Mystic/1.12" then use the \## escape method. I think that will cover any compatibility issues, but I still need to test against the final version of IREX to confirm without any doubt it needs \##.

In terms of Mystic anyone can just search for "Mystic" and use that as a trigger for \## too since Mystic does support both like MBSE/BinkD does.

If you ever need clarification on anything related to the FTSC, please don't hesitate to netmail me.

Thank you I appreciate that!

Likewise if you ever hear of or encounter anything that seems out of place that Mystic is doing please let me know so I can get it fixed up. Its at a pretty good place these days although there were growing pains getting there (as should probably be expected with one person developing 3 mailers, net/echo/tic tossers, and BBS software all at once lol).

... My reality check just bounced

--- Mystic BBS v1.12 A48 2022/01/19 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Re: Problem with filenames containing spaces
By: Oli to Andrew Leary on Thu Jan 20 2022 11:18 am

And it's only a problem with filenames that contains a whitespace character.

It's also a problem for filenames that contain any other "unsafe" characters that "SHOULD" (according to FTS-1026) be escaped.
--
digital man (rob)

Rush quote #77:
The world is, the world is, love and life are deep, maybe as his skies are wide Norco, CA WX: 75.9øF, 23.0% humidity, 3 mph NW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Rob wrote (2022-01-20):

And it's only a problem with filenames that contains a whitespace
character.

It's also a problem for filenames that contain any other "unsafe" characters that "SHOULD" (according to FTS-1026) be escaped.

You mean like 0x00 to 0x1F (control chars) and backslash (0x53)? How often do you use these in filenames? ;)

---
* Origin: Birds aren't real (2:280/464.47)

Re: Problem with filenames containing spaces
By: Oli to Rob Swindell on Thu Jan 20 2022 11:30 pm

Rob wrote (2022-01-20):

And it's only a problem with filenames that contains a whitespace
character.

It's also a problem for filenames that contain any other "unsafe" characters that "SHOULD" (according to FTS-1026) be escaped.

You mean like 0x00 to 0x1F (control chars) and backslash (0x53)? How often do you use these in filenames? ;)

Preferably, never, but I'm not in control of what characters are used in filenames received BinkP, the sender is.

Ideally, the BinkP spec would have been even *more* restrictive in the filename characters allowed (escaped or not), because filenames with colons, semicolons, asterisks, question marks and vertical-bars (pipes) are *not* what I would call "safe", yet they're expressly allowed as "safe" in the spec. :-(
--
digital man (rob)

Synchronet "Real Fact" #81:
Vertrauen has had the FidoNet node number 1:103/705 since 1992
Norco, CA WX: 76.0øF, 23.0% humidity, 3 mph NW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Rob wrote (2022-01-20):

And it's only a problem with filenames that contains a whitespace
character.

It's also a problem for filenames that contain any other "unsafe"
characters that "SHOULD" (according to FTS-1026) be escaped.

You mean like 0x00 to 0x1F (control chars) and backslash (0x53)? How
often do you use these in filenames? ;)

Preferably, never, but I'm not in control of what characters are used in filenames received BinkP, the sender is.

I wanted to express that in practice other (binkp-) reserved characters than whitespace are rarely used in filenames.

Ideally, the BinkP spec would have been even *more* restrictive in the filename characters allowed (escaped or not), because filenames with colons, semicolons, asterisks, question marks and vertical-bars (pipes) are *not* what I would call "safe", yet they're expressly allowed as "safe" in the spec. :-(

I think "safe" means safe in relation to the protocol, not filenames. Most unix filesystems do allow any character except "/" and \0. (https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations)

The protocol should be agnostic to filename restrictions of different filesystems. It should not modify filenames and transmit them transparently. The receiving system can then decide how to store them and which characters should be escaped or changed. Other protocols like HTTP or SFTP do the same.

How forbidden characters would be saved should have been specified in FTS-5005 (Advanced BinkleyTerm Style Outbound flow and control) though.

It was a bit stupid to remove the UTF8 extensions from the binkp spec. What happens to character >127 in filenames (and other strings) is undefined.

I also wonder why control characters have to be escaped in a binary protocol. And why whitespace was chosen as a delimiter. They could have used \0 and disallow \0 in strings. Then there wouldn't be any need for escapology. (Or instead of using a delimiter between parameters make everything (type-) length-value).

But it is what it is.

* Origin: Birds aren't real (2:280/464.47)