• Problem with filenames containing spaces

    From Paul Hayton@3:770/100 to All on Thu Jan 13 11:53:42 2022
    Hi there.

    A file was uploaded to Agency BBS by a user and was called

    MyGUI v1.0.2.26.zip

    There was a space between MyGUI and the V1. but I didn't think anything
    of it. I know better now :)

    I'd moved this file using sysop file editor tools in my Mystic BBS and hatched it from Agency BBS to the wider fsxNet.

    Mystic BBS logs show:

    ----------------- MUTIL v1.12 A47 2021/11/06 Sun, Jan 09 2022 (loglevel 3)
    + Jan 09 17:09:35 Startup using mailin.ini
    - Jan 09 17:09:35 EXEC FileToss
    - Jan 09 17:09:35 EXEC ImportEchoMail
    + Jan 09 17:09:35 Process: Toss FDN/TIC Files
    + Jan 09 17:09:35 Waiting for BUSY nodes
    + Jan 09 17:09:35 Scanning Hatches
    + Jan 09 17:09:35 Hatching: MyGUI v1.0.2.26.zip from Mystic BBS Utils, Mods Etc.
    + Jan 09 17:09:35 Tossing to 21:1/100
    + Jan 09 17:09:35 Results: 0 import, 1 toss, 1 hatch, 0 bad in 0.02s


    The TIC file from Mystic contains

    Created By Mystic BBS v1.12 A47
    Area FSX_MUTL
    AreaDesc Mystic BBS Utils, Mods Etc.
    File MyGUI v1.0.2.26.zip
    Size 1669424
    CRC d39eeb54
    Replaces MyGUI v1.0.2.26.zip


    Htick at 21:1/100 HUB then tosses the file to other nodes...

    ----------------------- Sun 09 Jan 2022, htick/lnx 1.9.0-cur 2021-03-11
    1 Jan:09:2022:17:11:00 Start
    7 Jan:09:2022:17:11:00 Checking tmp dir
    C Jan:09:2022:17:11:00 Start tossing...
    7 Jan:09:2022:17:11:00 Processing Tic-File /hub/echomail/in/MyGUI v1.0.2.26.tic
    7 Jan:09:2022:17:11:00 File "MyGUI v1.0.2.26.zip": size: 1669424, area: FSX_MUTL, from: 21:1/101, orig: 21:1/101
    M Jan:09:2022:17:11:00 Moved /hub/echomail/in/MyGUI v1.0.2.26.zip to /ftn/files/fsx/fsx_mutl/MyGUI v1.0.2.26.zip
    M Jan:09:2022:17:11:00 Report file /ftn/files/announce/1cemsgdy.tic created for file MyGUI v1.0.2.26.zip
    S Jan:09:2022:17:11:00 Linked: /ftn/files/fsx/fsx_mutl/MyGUI v1.0.2.26.zip
    S Jan:09:2022:17:11:00 to: /hub/filebox/fsxnet_z21n2n100/MyGUI v1.0.2.26.zip


    Using BinkD as the mailer at 21:1/100 I then noticed some BBS nodes polling in were having this issue:

    + 09 Jan 19:19:38 [24867] call to 21:1/107@fsxnet
    09 Jan 19:19:38 [24867] trying bbs.thebytexchange.com [204.12.198.27]...
    09 Jan 19:19:39 [24867] connected
    + 09 Jan 19:19:39 [24867] outgoing session with bbs.thebytexchange.com:24554 [204.12.198.27]
    - 09 Jan 19:19:39 [24867] OPT CRAM-MD5-39f913bebc0dbe388a3671b63e62f6f8
    + 09 Jan 19:19:39 [24867] Remote requests MD mode
    - 09 Jan 19:19:39 [24867] SYS The ByteXchange BBS
    - 09 Jan 19:19:39 [24867] ZYZ Nugax
    - 09 Jan 19:19:39 [24867] TIME Sun, 09 Jan 2022 00:19:39 -0600
    - 09 Jan 19:19:39 [24867] VER Mystic/1.12A47 binkp/1.0
    - 09 Jan 19:19:39 [24867] BUILD 2020/10/13 12:55:27 Linux/64
    + 09 Jan 19:19:39 [24867] addr: 1:19/37@fidonet
    + 09 Jan 19:19:39 [24867] addr: 40:100/2@cybernet (n/a or busy)
    + 09 Jan 19:19:39 [24867] addr: 21:1/107@fsxnet
    + 09 Jan 19:19:39 [24867] addr: 10:102/1@araknet (n/a or busy)
    + 09 Jan 19:19:39 [24867] addr: 618:200/32@micronet (n/a or busy)
    + 09 Jan 19:19:39 [24867] addr: 42:256/6@sfnet (n/a or busy)
    + 09 Jan 19:19:39 [24867] addr: 700:100/12@spooknet (n/a or busy)
    + 09 Jan 19:19:39 [24867] addr: 42:972/1@dorenet (n/a or busy)
    + 09 Jan 19:19:39 [24867] addr: 11:1/200@wwivftn (n/a or busy)
    + 09 Jan 19:19:40 [24867] pwd protected session (MD5)
    + 09 Jan 19:19:40 [24867] sending /hub/filebox/fsxnet_z21n1n107/MyGUI v1.0.2.26.zip as MyGUI\x20v1.0.2.26.zip (1669424)
    - 09 Jan 19:19:40 [24867] QSIZE 0 files 0 bytes
    ? 09 Jan 19:19:40 [24867] M_GOT: cannot parse args
    + 09 Jan 19:19:40 [24867] done (to 21:1/107@fsxnet, failed, S/R: 0/0 (0/0 bytes))

    incoming nodes (earlier Mystic version) seem to have the same problem.

    + 09 Jan 23:58:08 [6668] incoming session with 47-220-170-115.gtwncmkt04.res.dyn.suddenlink.net [47.220.170.115]
    - 09 Jan 23:58:08 [6668] SYS Cold War Computing BBS
    - 09 Jan 23:58:08 [6668] ZYZ Jeff
    - 09 Jan 23:58:08 [6668] TIME Sun, 09 Jan 2022 04:58:08 -0600
    - 09 Jan 23:58:08 [6668] VER Mystic/1.12A46 binkp/1.0
    - 09 Jan 23:58:08 [6668] BUILD 2020/08/26 19:01:33 Raspberry Pi/32
    + 09 Jan 23:58:08 [6668] addr: 21:1/180@fsxnet
    + 09 Jan 23:58:08 [6668] pwd protected session (MD5)
    + 09 Jan 23:58:08 [6668] sending /hub/filebox/fsxnet_z21n1n180/MyGUI v1.0.2.26.zip as MyGUI\x20v1.0.2.26.zip (1669424)
    - 09 Jan 23:58:08 [6668] QSIZE 0 files 0 bytes
    ? 09 Jan 23:58:09 [6668] M_GOT: cannot parse args
    + 09 Jan 23:58:09 [6668] done (from 21:1/180@fsxnet, failed, S/R: 0/0 (0/0 bytes))

    My fix was to delete the file out of file boxes to get traffic flowing again.

    I spoke with the Mystic author and his reply was

    [snip]

    This seems to be related to a long standing issue with BinkD escaping filenames incorrectly. You'll have to get it fixed in BinkD.

    A47 has a workaround for the BinkD bugs but A46 would not.

    v1.0.2.26.zip as MyGUI\x20v1.0.2.26.zip (1669424)

    This is not a properly escaped filename being sent by BinkD as it does not follow the BINKP protocol specifications for filename escaping:

    5.2 File Name Issues
    --------------------
    In Mailer-parseable commands that contain a file name, the file name MUST NOT include a whitespace (ASCII value 20 hex). The file name SHOULD NOT include symbols other than alphanumeric (A-Z,a-z,0-9) and safe characters as defined below in BNF. All other symbols are to be considered unsafe and SHOULD be escaped in the form of two hexadecimal digits preceded by a backslash (e.g. a whitespace must be transmitted as "\20").

    filename = *pchar
    pchar = unreserved | escape
    unreserved = ALPHA | DIGIT | safe
    safe = "@" | "&" | "=" | "+" | "%" | "$" | "-" | "_" |
    "." | "!" | "(" | ")" | "#" | "|"
    escape = "\" HEX HEX

    [snip]

    Is it possible please for BinkD to be updated so that if a file name with a space in it is sent using BinkD to a remote system the filename escaping is transmitted as per suggestions above?

    With thanks, Paul.

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Stas Mishchenkov@2:460/5858 to Paul Hayton on Thu Jan 13 10:15:38 2022
    Hi, Paul!

    13 ï­¢ 22 11:53, Paul Hayton -> All:

    This is not a properly escaped filename being sent by BinkD as it does
    not follow the BINKP protocol specifications for filename escaping:

    http://ftsc.org/docs/fts-1026.001

    Publication: FTS-1026
    Revision: 1
    Title: Binkp/1.0 Protocol specification
    Authors: Michiel Broek
    Stas Degteff
    Issue Date: 1 December 2005
    Review Date: 1 December 2007

    [...skipped...]

    5.2 Escaping method for illegal characters in Command Argument
    --------------------------------------------------------------

    In some cases there is a need to send illegal characters in
    the command argument (usually the file name). These characters
    SHOULD be escaped using form of 4th symbols sequence: "\", "x"
    and two hexadecimal digits (digits "a".."f" may be any case).
    Examples:
    whitespace (" ") excaped as "\x20"; pipe ("|") escaped as "\x7c".

    If escaping may be used in some command argument, mailer MUST
    allways escape character '\' for prevent uncertainty.

    In FSP-1011.003 the escape method is specified as two hexadecimal
    digits preceded with a backslash (e.g. a whitespace is
    transmitted as "\20"). Some mailers have implemented that method.
    It is advised to have a setting for specific nodes to sent escaped
    characters using the incorrect method.

    Any mailer SHOULD decode "\20" into space in file names for
    compatibility purposes.


    5.3 Non-ASCII Characters in Command Argument Symbol String
    ----------------------------------------------------------

    Generally, mailer SHOULD use only characters from the ASCII range
    [32...126] in the symbol strings for command arguments.
    Other characters MAY be used only in M_NUL command argument in
    plain form.
    Implementation recommendation: use isprint() function (ISO C).


    5.4 File Name Issues
    --------------------

    In binkp commands that contain a file name, the file name MUST NOT
    include a whitespace (ASCII value 20 hex). If name of file to send
    contents space, it MUST be escaped. The file name SHOULD NOT
    include symbols other than alphanumeric (A-Z,a-z,0-9) and safe
    characters as defined below in BNF. All other symbols are to be
    considered unsafe and SHOULD be escaped. Space and backslash (\)
    MUST be escaped.
    For example: file name "abcd e.0f@" must be transmitted in form
    "abcd\x20e.0f@".

    filename= *pchar
    pchar = plain | escaped
    plain = alpha | digit | safe
    safe = "!" | """ | "#" | "$" | "%" | "&" | "'" | "(" | ")" |
    "*" | "+" | "," | "-" | "." | "/" | ":" | ";" | "<" |
    "=" | ">" | "?" | "@" | "[" | "]" | "^" | "_" | "`" |
    "{" | "|" | "}" | "~"
    alpha = "A" | "B" | ... | "Z" | "a" | "b" | ... | "z"
    digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
    escaped = "\x" HEX HEX
    HEX = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" |
    "c" | "d" | "e" | "f"

    Note: some characters are illegal for file names in some OS such as
    DOS or Windows. The protocol do not impose limitations for these
    characters in file names and if mailer receives OS incompatible
    file name then it's reaction determine on a implementation: mailer
    may be destructive skip file, save file with some legal name or
    other.

    The protocol does not impose limitations on the file name length
    other than those arising from the finite length of the binkp frame
    itself. Really file name length can't exceed 32751 bytes.


    Have nice nights.
    Stas Mishchenkov.

    --- ‘â à®áâì - íâ® ª®£¤  ¢¨¤¨èì á¨á쪨 ¨ ¢á¯®¬¨­ ¥èì, çâ® § ¡ë« ¬®«®ª  ªã¯¨âì
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Paul Hayton@3:770/100 to Stas Mishchenkov on Fri Jan 14 10:42:38 2022
    On 13 Jan 2022 at 10:15a, Stas Mishchenkov pondered and said...

    This is not a properly escaped filename being sent by BinkD as it doe not follow the BINKP protocol specifications for filename escaping:

    http://ftsc.org/docs/fts-1026.001

    Hi Stas

    I am not a developer so am unsure what it is you are saying by posting this reply?

    Best, Paul

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Oli@2:280/464.47 to Paul Hayton on Thu Jan 13 23:13:54 2022
    Paul wrote (2022-01-14):

    On 13 Jan 2022 at 10:15a, Stas Mishchenkov pondered and said...

    This is not a properly escaped filename being sent by BinkD as
    it doe not follow the BINKP protocol specifications for
    filename escaping:

    http://ftsc.org/docs/fts-1026.001

    Hi Stas

    I am not a developer so am unsure what it is you are saying by posting this reply?

    Like it's always the same. It's never Mystic's problem, the others are doing it wrong. (Why should the guru read the fucking manual? Why should he ask for advice? He always knows better ...)

    As far as I understand it, the quote in your mail was from an older spec and not the most recent FTSC. Mailers must send \x20, but should accept \20 too. Sending \20 is a bug in Mystic, but most mailers would accept it. Not understanding \x20 was a bug in Mystic in previous versions.

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From deon@3:633/509 to Paul Hayton on Fri Jan 14 09:27:34 2022
    Re: Re: Problem with filenames containing spaces
    By: Paul Hayton to Stas Mishchenkov on Fri Jan 14 2022 10:42 am

    I am not a developer so am unsure what it is you are saying by posting this reply?

    James has quoted a FTS proposal. (hex chars are represent as \nn)

    Stats quoted the accepted technical standard. (hex chars are presented as \xnn, but should also accept/understand any mailer using \nn) - with a later date IIRC.

    binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.

    Ergo, while he is saying binkd is doing it wrong, it is in fact mystic that is doing it wrong (from a standards point of view).


    ...ëîåï
    --- SBBSecho 3.14-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Paul Hayton@3:770/100 to deon on Fri Jan 14 16:07:36 2022
    On 14 Jan 2022 at 09:27a, deon pondered and said...

    James has quoted a FTS proposal. (hex chars are represent as \nn)
    Stats quoted the accepted technical standard. (hex chars are presented
    as \xnn, but should also accept/understand any mailer using \nn) - with
    a later date IIRC.
    binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.
    Ergo, while he is saying binkd is doing it wrong, it is in fact mystic that is doing it wrong (from a standards point of view).

    OK thanks for the clarification. I wonder if he monitors this echo? If not I could always pass this info on.

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From mark lewis@1:3634/12.73 to Paul Hayton on Fri Jan 14 05:36:44 2022

    On 2022 Jan 14 16:07:36, you wrote to deon:

    James has quoted a FTS proposal. (hex chars are represent as \nn)
    Stats quoted the accepted technical standard. (hex chars are presented
    as \xnn, but should also accept/understand any mailer using \nn) -
    with a later date IIRC. binkd has implemented the procotol as per the
    standard, whereas james has implemented as per the proposal. Ergo,
    while he is saying binkd is doing it wrong, it is in fact mystic that
    is doing it wrong (from a standards point of view).

    OK thanks for the clarification. I wonder if he monitors this echo? If not I could always pass this info on.

    i would pass it back (in the MYSTIC echo) for completion since it helps to close the topic as posted over there ;)

    )\/(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!"
    ... I've been pursuing a path of alternate reality
    ---
    * Origin: (1:3634/12.73)
  • From James Coyle@1:129/215 to Oli on Fri Jan 14 12:11:14 2022
    Like it's always the same. It's never Mystic's problem, the others are doing it wrong. (Why should the guru read the fucking manual? Why should he ask for advice? He always knows better ...)

    As usual you immediately showcase your childish behavior and complete disregard for being a decent human, for no reason at all.

    It doesn't matter how large of an emotional meltdown you have, its not going to change how software actually works. In Paul's case the failure was because of the format of the escaped file name and that can be a problem with some mailers when filenames are escaped the way BINKD does.

    Yes, FTS did change it but they changed it *15 YEARS* after the other method was already in the wild and implemented. That change doesn't magically make legacy software work differently.

    I don't know what "advice" you think I should ask for. The only way for Paul's problem to be fixed would be if BINKD would escape as originally intended or for those people to update to different software. Older software cannot be updated. There is nothing *I* can do that would fix the problem he saw.

    In Mystic's case it handles either format correctly and it escapes as originally intended by the creators of BINKP. It does that because its the only way that works with 100% of implementations we all tested against. You can disagree if you want to, but that has nothing to do with what Paul posted here.

    I could care less if BINKD changes it and its easily arguable that they shouldn't change it. But that doesn't change the way legacy software works no matter how big of an emotional meltdown you have over it.

    ... Confucius say: "Its stuffy inside fortune cookie"

    --- Mystic BBS v1.12 A48 2022/01/12 (Windows/32)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Oli@2:280/464.47 to James Coyle on Fri Jan 14 20:01:36 2022
    James wrote (2022-01-14):

    Yes, FTS did change it but they changed it *15 YEARS* after the other method was already in the wild and implemented. That change doesn't magically make legacy software work differently.

    sure ;-P

    https://github.com/pgul/binkd/blob/45986b77161a366ea3d258a01dad442d3d21d81e/tools.c#L399
    https://github.com/pgul/binkd/blob/45986b77161a366ea3d258a01dad442d3d21d81e/tools.c#L419

    https://github.com/pgul/binkd/commit/b4e7b17b7f0621abc1b3017307dd1382eaa039d9


    ftp://cvs.happy.kiev.ua/pub/fidosoft/mailer/binkd/

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From James Coyle@1:129/215 to Oli on Fri Jan 14 14:25:25 2022
    method was already in the wild and implemented. That change doesn't magically make legacy software work differently.

    sure ;-P

    https://github.com/pgul/binkd/blob/45986b77161a366ea3d258a01dad442d3d21d81

    I can't figure out what you're trying to show there, but I don't think you know either. Thats not the escaping code if that is what you're going for. This is:

    char *strquote (char *s, int flags)
    {
    ... (cut some stuff) ...
    sprintf (r + i, "\\x%02x", *(unsigned char *) s);
    }

    And at least in the version you're showing me, BINKD does not implement the per-connection option for legacy escaping as per the FTS update. If it did, then Paul would not have the issue he's having and thus why I sent him in this direction.

    Paul's issue cannot be solved unless BINKD is updated or his downlink changes software versions. There is literally nothing I can do to help him. I don't care if BINKD wants to support escaping in legacy mode as per FTS or not personally.

    And for the record. Here's Mystic's code for this. It more closely follows FTS in comparison to the link I just looked at which you sent, so I don't know what you're complaining about:

    Function TBinkP.EscapeFileName (Const Str: String) : String;
    { Replace illegal characters with \## escaped sequences }
    Const
    SafeChars = ['!', '"', '#', '$', '%', '&', '''', '(', ')', '*', '+', ',',
    '-', '.', '/', ':', ';', '<', '=', '>', '?', '@', '[', ']',
    '^', '_', '`', '{', '}', '~'];
    AlphaChars = ['0'..'9','A'..'Z','a'..'z'];
    Var
    Count : Byte;
    Begin
    Result := '';

    For Count := 1 to Length(Str) Do
    If (Str[Count] in SafeChars) or (Str[Count] in AlphaChars) Then
    Result := Result + Str[Count]
    Else
    { 0=Original BINKP (Argus, IREX, Amiga) }
    { 1=Updated (Post 2010+ FTS updates ie BINKD uses this) }
    Case EscapeMode of
    1 : Result := Result + '\x' + strI2H(Byte(Str[Count]), 2);
    Else
    Result := Result + '\' + strI2H(Byte(Str[Count]), 2);
    End;
    End;

    ... One tequila, two tequila, three tequila, floor.

    --- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From James Coyle@1:129/215 to deon on Fri Jan 14 15:34:58 2022
    binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.

    Just for clarification: Mystic does both. Or at least it does as of a couple hours after the issue was first brought to my attention (which was a couple years ago I believe).

    And in the latest version it also allows it to be configured on a per-node basis, so if you have one downlink with a legacy mailer that won't work with anything but /## and one that only supports /x## you can configure each node accordingly.

    ... They say there's always one weirdo on the bus, but I couldn't find them!

    --- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Oli@2:280/464.47 to James Coyle on Fri Jan 14 22:20:24 2022
    James wrote (2022-01-14):

    I can't figure out what you're trying to show there, but I don't think
    you know either.

    Of course you know better what I know.

    Thats not the escaping code if that is what you're
    going for. This is:

    char *strquote (char *s, int flags)
    {
    ... (cut some stuff) ...
    sprintf (r + i, "\\x%02x", *(unsigned char *) s);
    }

    I linked that.

    And at least in the version you're showing me, BINKD does not implement the per-connection option for legacy escaping as per the FTS update.

    There is no such thing as legacy escaping. Please show us a binkd version from the 90s that uses \## instead of \x##. I don't think there is one. AFAIK it was always \x##.

    If
    it did, then Paul would not have the issue he's having and thus why I
    sent him in this direction.

    Nope, it's a bug in Mystic.

    Paul's issue cannot be solved unless BINKD is updated or his downlink changes software versions. There is literally nothing I can do to help him. I don't care if BINKD wants to support escaping in legacy mode as per FTS or not personally.

    Of course you don't (and know better). Maybe your users do care though.

    And for the record. Here's Mystic's code for this. It more closely follows FTS in comparison to the link I just looked at which you sent, so I don't know what you're complaining about:

    So you say that binkp should implement a workaround, because some Mystic versions don't understand a "\x20" specified by a > 15 years old FTS?

    Function TBinkP.EscapeFileName (Const Str: String) : String;
    { Replace illegal characters with \## escaped sequences }
    ^^^ wrong

    Else
    { 0=Original BINKP (Argus, IREX, Amiga) }

    Argus indeed expects \##. But it's not "original binkp".

    { 1=Updated (Post 2010+ FTS updates ie BINKD uses this) }

    FSP-1011 had an error and "some mailers have implemented that method". For that reason FTS-1026 states that "any mailer SHOULD decode \20 into space in file names for compatibility purposes". FTS-1026 did not update/change \20 to \x20, but added \20 as an alternative escaping method for non-

    binkd also added a workaround for non-compliant mailers (but only one way).

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From Oli@2:280/464.47 to James Coyle on Fri Jan 14 22:28:09 2022
    James wrote (2022-01-14):

    binkd has implemented the procotol as per the standard, whereas
    james has implemented as per the proposal.

    Just for clarification: Mystic does both. Or at least it does as of a couple hours after the issue was first brought to my attention (which was a couple years ago I believe).

    And why couldn't it accept standard-compliant filenames?

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From deon@3:633/509 to James Coyle on Sat Jan 15 08:30:53 2022
    Re: Re: Problem with filenames containing spaces
    By: James Coyle to deon on Fri Jan 14 2022 03:34 pm

    binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.

    Just for clarification: Mystic does both. Or at least it does as of a couple hours after the issue was first brought to my attention
    (which was a couple years ago I believe).

    And in the latest version it also allows it to be configured on a per-node basis, so if you have one downlink with a legacy mailer that
    won't work with anything but /## and one that only supports /x## you can configure each node accordingly.

    Something for me doesnt add up with your reply, so I'll re-iterate what I think you saying and you can set me straight...

    Are you saying that Mystic's binkp will send a file to a node using an escape sequence of \## or \x## depending on how the sysop has configured that node in Mystic configuration?

    The issue at hand is Mystic's binkp receiving a file, where the sender encodes ASCII < 32 as \x## - Mystic cannot process it. Your reply to this was the sending system shouldnt encode that way (it should be using \##) and thus must be changed.

    Did I get that right?


    ...ëîåï
    --- SBBSecho 3.14-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alexey Fayans@2:5030/1997 to deon on Sat Jan 15 21:25:04 2022
    Hello deon!

    On Sat, 15 Jan 2022 at 08:30 +1100, you wrote to James Coyle:

    Did I get that right?

    No. Binkd encodes filename correctly according to FTS. Your downlink must update their software to a newer version that understands proper encoding.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From deon@3:633/509 to Alexey Fayans on Sun Jan 16 09:41:37 2022
    Re: Problem with filenames containing spaces
    By: Alexey Fayans to deon on Sat Jan 15 2022 09:25 pm

    On Sat, 15 Jan 2022 at 08:30 +1100, you wrote to James Coyle:

    Did I get that right?

    No. Binkd encodes filename correctly according to FTS. Your downlink must update their software to a newer version that understands
    proper encoding.

    I know how Binkd encodes files.

    My question was directed at James.


    ...ëîåï
    --- SBBSecho 3.14-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alexey Fayans@2:5030/1997 to deon on Sun Jan 16 02:31:18 2022
    Hello deon!

    On Sun, 16 Jan 2022 at 09:41 +1100, you wrote to me:

    Did I get that right?
    No. Binkd encodes filename correctly according to FTS. Your
    downlink must update their software to a newer version that
    understands proper encoding.
    I know how Binkd encodes files.
    My question was directed at James.

    Since asked question in BINKD echo (as opposed to netmail), I felt free to answer it. And my aim was to explain why you didn't get it right.

    So, again, binkd will not change the way it encodes filenames, so the only way the issue can be fixed is to upgrade Mystic software at receiver's end.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From mark lewis@1:3634/12.73 to Alexey Fayans on Sun Jan 16 05:58:46 2022

    On 2022 Jan 16 02:31:18, you wrote to deon:

    My question was directed at James.

    Since asked question in BINKD echo (as opposed to netmail), I felt free to answer it. And my aim was to explain why you didn't get it right.

    deon was trying to repeat james' statement back to james so deon would know if he had properly understood what james had said... he was not trying to say how binkd works when encoding certain characters in file names... please don't confuse things any more than they already are ;)

    )\/(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!"
    ... Go ahead, jump. 100,000 lemmings can't be wrong.
    ---
    * Origin: (1:3634/12.73)
  • From James Coyle@1:129/215 to deon on Mon Jan 17 11:00:11 2022
    Are you saying that Mystic's binkp will send a file to a node using an escape sequence of \## or \x## depending on how the sysop has configured that node in Mystic configuration?

    Yes.

    For incoming filenames Mystic handles all variations.

    For outbound filenames it uses \## (because any mailer that does \x## will also accept \##, but mailers that accept \## wont accept \x##). Its the most compatible method. This is how it worked up to A47.

    Then in A48 I went further and added in the option in the node configuration so you can choose per-connection just in case there someday is a newer mailer in the future that does \x## but can't do \##...

    This A48 addition was as a result of the recommendation that was pointed out to me in FTS-1026.001: http://ftsc.org/docs/fts-1026.001

    "In FSP-1011.003 the escape method is specified as two hexadecimal digits preceded with a backslash (e.g. a whitespace is transmitted as "\20"). Some mailers have implemented that method. It is advised to have a setting for specific nodes to sent escaped characters using the incorrect method."

    Mystic implements the recommendation made in the last sentence but BINKD does not as far as I know? So the solution to Paul's problem is to have BINKD follow the FTS recommendation, or for the person to upgrade their software version. I can't help him.

    ... Do vegetarians eat animal crackers?

    --- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Oli@2:280/464.47 to James Coyle on Mon Jan 17 18:05:34 2022
    James wrote (2022-01-17):

    Are you saying that Mystic's binkp will send a file to a node using
    an escape sequence of \## or \x## depending on how the sysop has
    configured that node in Mystic configuration?

    Yes.

    For incoming filenames Mystic handles all variations.

    If that were true, then the problem that Paul saw shouldn't have happened:

    - 09 Jan 19:19:39 [24867] VER Mystic/1.12A47 binkp/1.0
    - 09 Jan 19:19:39 [24867] BUILD 2020/10/13 12:55:27 Linux/64
    [...]
    + 09 Jan 19:19:40 [24867] sending /hub/filebox/fsxnet_z21n1n107/MyGUI v1.0.2.26.zip as MyGUI\x20v1.0.2.26.zip (1669424)
    - 09 Jan 19:19:40 [24867] QSIZE 0 files 0 bytes
    ? 09 Jan 19:19:40 [24867] M_GOT: cannot parse args

    For outbound filenames it uses \## (because any mailer that does \x##
    will also accept \##, but mailers that accept \## wont accept \x##). Its the most compatible method. This is how it worked up to A47.

    This is not what FTS-1026 recommends. It also doesn't work with every legacy mailer. What you don't understand is that FSP-1011 specified the wrong escape method. Binkd used \x## long before FSP-1011 and added \## as a reaction to a mistake in FSP-1011. It is not the most compatible method.

    Then in A48 I went further and added in the option in the node configuration so you can choose per-connection just in case there someday is a newer mailer in the future that does \x## but can't do \##...

    🤦

    This option was meant for mailers that uses the incorrect escape sequence \## (like Mystic does).

    This A48 addition was as a result of the recommendation that was pointed out to me in FTS-1026.001: http://ftsc.org/docs/fts-1026.001

    "In FSP-1011.003 the escape method is specified as two hexadecimal digits preceded with a backslash (e.g. a whitespace is transmitted as "\20"). Some mailers have implemented that method. It is advised to have a
    setting for specific nodes to sent escaped characters using the incorrect method."

    as it is clearly explained in the quoted FTS.

    Mystic implements the recommendation made in the last sentence but BINKD does not as far as I know?

    So you expect that binkd implement a feature that is not implemented in a release version of Mystic? (or only recently). And you expect that binkd should implement workarounds for buggy Mystic mailers?

    So the solution to Paul's problem is to have
    BINKD follow the FTS recommendation, or for the person to upgrade their software version. I can't help him.

    I would also recommend upgrading from the Mystic mailer to some FTS compliant mailer and to one that supports the faster binkp/1.1 protocol.

    Again: is there any mailer used today that doesn't understand \x## (which is not called Mystic)?

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From James Coyle@1:129/215 to Oli on Tue Jan 18 11:33:19 2022
    This is not what FTS-1026 recommends. It also doesn't work with every legacy mailer. What you don't understand is that FSP-1011 specified the wrong escape method.

    FTS-1026 recommends it to be a per-connection configurable option as I have shown here, which is implemented in Mystic. It is not an option in BINKD and if it were, this would not be a problem for Paul. Those are the facts.

    This option was meant for mailers that uses the incorrect escape
    sequence \## (like Mystic does).

    Again, you're literally quoting a message that says Mystic can operate in either way, which is the FTS recommendation. Grow up and stop being so disingenious all of the time.

    So you expect that binkd implement a feature that is not implemented in a

    No, as I have said in messages prior: I don't care if BINKD implements it as an option or not. But the only way for Paul's problem to be solved is for BINKD to implement the FTS recommendation on how to handle escaping. I cannot help him.

    Stop trying twist everything to create confusion, and just let it go.

    I would also recommend upgrading from the Mystic mailer to some FTS compliant mailer and to one that supports the faster binkp/1.1 protocol.

    As with every single thing you've said in this message, none of this is true.

    The difference between BINKP 1.0/NR and BINKP 1.1 has nothing to do with performance. It simply sends an extra round of EOB for handling file requests differently.

    You're saying the \## was a typo and not used anywhere, which is absolutely false. The FTS documentation on the subject specifically says mailers DO use that escaping. In fact, older mailers either did no escaping at all or only use \##.

    There are no FTS compliance issues with Mystic's echomail, and it probably transmits more FTN-style mail than any other software. If there was an actual problem then speak up. And Paul has worked with me enough to know if there was a problem I would fix it for him quickly, and he wouldn't have to go through this drama-filled daycare to get help.

    It doesn't matter how many more years you go on trying to harass me and spew a bunch of misinformation about me or Mystic, reality will never agree with you.

    I am sure everyone here is more than tired of this, so just move on.

    --- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Oli@2:280/464.47 to James Coyle on Tue Jan 18 20:44:11 2022
    James wrote (2022-01-18):

    This is not what FTS-1026 recommends. It also doesn't work with
    every legacy mailer. What you don't understand is that FSP-1011
    specified the wrong escape method.

    FTS-1026 recommends it to be a per-connection configurable option as I have shown here, which is implemented in Mystic. It is not an option in BINKD and if it were, this would not be a problem for Paul. Those are
    the facts.

    Do you really believe everyone is too stupid to recognize your discussion strategy?

    You are trying to make non-standard behavior (bug) of Mystic a feature and explaining that every other mailer should implement a workaround for Mystic's problems (or it's not your problem anymore). You also do your best to not mention the fact, that some Mystic versions were not able to process filenames with standard compliant escaping (\x##).

    Again, look at the old source code of binkd, which was and still is the reference implementation. Where is the code that sends \## escape sequences?

    ftp://cvs.happy.kiev.ua/pub/fidosoft/mailer/binkd/

    It always was and still is \x##.

    This option was meant for mailers that uses the incorrect escape
    sequence \## (like Mystic does).

    Again, you're literally quoting a message that says Mystic can operate in either way, which is the FTS recommendation.

    That is not the point. Why would anyone who is using a standard compliant mailer care, that Mystic can be configured to send incorrect escape codes? (or has to be explicitly configured for sending the correct escape code)

    Grow up and stop being so disingenious all of the time.

    Seriously?

    So you expect that binkd implement a feature that is not
    implemented in a

    No, as I have said in messages prior: I don't care if BINKD implements it as an option or not. But the only way for Paul's problem to be solved is for BINKD to implement the FTS recommendation on how to handle escaping.
    I cannot help him.

    And we cannot help Mystic users with their broken software.

    Stop trying twist everything to create confusion, and just let it go.

    Me?

    I would also recommend upgrading from the Mystic mailer to some FTS
    compliant mailer and to one that supports the faster binkp/1.1
    protocol.

    As with every single thing you've said in this message, none of this is true.

    No matter what you say, it is still true that I would recommend to use another mailer.

    The difference between BINKP 1.0/NR and BINKP 1.1 has nothing to do with performance. It simply sends an extra round of EOB for handling file requests differently.

    Here I was indeed wrong, binkp/1.0 can be as fast as binkp/1.1 (for stable connections). The slowness of Mystic's mailer must had some other reasons (maybe it is faster nowadays, but performance was not great in 2020. I switched to another uplink and Paul switched to binkd since then. So I don't know if Mystic's mailer has improved).

    You're saying the \## was a typo and not used anywhere, which is absolutely false. The FTS documentation on the subject specifically says mailers DO use that escaping. In fact, older mailers either did no escaping at all or only use \##.

    There are no FTS compliance issues with Mystic's echomail, and it
    probably transmits more FTN-style mail than any other software.

    What the fuck are you talking about now? This was never about echomail.

    If there was an actual problem then speak up.

    I did speak up some time ago, when Mystic used to mangle in-transit echomail. Your response was to throw a fit and react aggressively against the messenger.

    I warned about that it could produce dupes. And it did. Mystic was THE software that produced most of the problems with echomail in Fsxnet.

    And Paul has worked with
    me enough to know if there was a problem I would fix it for him quickly, and he wouldn't have to go through this drama-filled daycare to get help.

    And now he uses binkd and hpt.

    It doesn't matter how many more years you go on trying to harass me and spew a bunch of misinformation about me or Mystic, reality will never agree with you.

    I know Mystic is your baby, but since when is harassing a thing a thing?

    I'm really not interested to harass you. But I'm not the only one who is sick of your behavior. It doesn't matter how many more years you go on trying to harass others and spew a bunch of misinformation, reality will never agree with you.

    I am sure everyone here is more than tired of this, so just move on.

    Yes, we are tired of your bullshit too. Fix your software and don't burden everyone else with the problems your software creates. It's as simple as that.


    Let's wrap it up:
    - You implemented Mystic binkp mailer on base of FSP-1011 (http://ftsc.org/docs/old/fsp-1011.003), which was only a proposal and was never released as a standard (right or wrong?).
    - Now Mystic is sending incorrect escape sequences (if not configured otherwise in the newest (alpha) version?).
    - You are convinced that sending an incorrect escape (\##) is the most compatible way.
    - Binkd (and every other mailer) should do the same or implement workarounds for non-compliant software.
    - Also: not understanding the correct escape sequences is not the problem of the software that doesn't understand it.

    So Mystic is fighting to save the incorrect \## forever, because of some old legacy software (whichever that is) or something (whatever) ...

    .... meanwhile, Binkd, qico, BinkIt and others are doing just fine with \x##

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From James Coyle@1:129/215 to Oli on Tue Jan 18 15:50:59 2022
    FTS-1026 recommends it to be a per-connection configurable option as have shown here, which is implemented in Mystic. It is not an Ol> Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> JC> option BINKD Ol> JC> Ol> JC> and if it Ol> JC> Ol> JC> were, this Ol> JC> Ol> Ol> JC> Ol> JC> JC> would not Ol> JC> Ol> Ol> JC> Ol> JC> JC> be a Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> problem Ol> JC> Ol> JC> Ol> JC> Ol> JC> for Ol> JC> JC> Paul. Ol> JC> Ol> JC> Ol> Ol> JC> Ol> JC> Ol> Ol> JC> Ol> JC> JC> Ol> JC> JC> Those are the Ol> JC> Ol> JC> Ol> JC> Ol> JC> facts.

    Do you really believe everyone is too stupid to recognize your discussion strategy?

    I have a two part answer to this:

    1) There is no strategy. I quoted the FTS and I linked it, you can't get more clear than that. There is no animosity between BINKP developers. We're not trying to make incompatible software. There is no competition. We all want our software to work together; its literally the point of integrating BINKP in our products.

    This idea you've dreamed up that we have a "strategy" is not a conclusion any rational person would come to. I've done all I can do on the Mystic side for Paul, its up to BINKD to do more if they choose to. I'll even do it myself and submit a pull request if they will accept it.

    When it was brought to my attention by Frank (Netsurge), I looked into it and admitted I should have implemented the per-session escaping option and then I did within a day or so. I could have done it better, and when I realized I should have, I changed it. This is where BINKD is now (or not, up to them).

    2) I have received multiple netmails TODAY ALONE from prominent FidoNet authors and hubs within the community, all of which cite you as being a problem in the way you behave. I think that confirms your question. You are an unreasonable person to deal with regardless of the situation.

    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). They seem like good guys who fell into your web of bullshit, and you used it to get away with hurting a community that needs all the help it can get.

    It always was and still is \x##.

    The FTS (that you accuse me of ignoring) disagrees with you as it specfically says some mailers implement the \## and that it should be an option. My own communities' testing confirms it. Just stop making shit up man.

    I have to be honest, the rest of your response is so unhinged even compared to your usual unhinged responses. It seriously makes me worried for you, like you're under the influence of some serious drugs or something. I hope you're alright. Just move on dude! FidoNet and this perceived notion that I am some sort of villian isn't worth your mental sanity...

    That is not the point. Why would anyone who is using a standard compliant mailer care, that Mystic can be configured to send incorrect escape
    codes? (or has to be explicitly configured for sending the correct
    escape code)

    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:

    The best lesson I got when I started implementing FidoNet into Mystic was from Marc Lewis. He is a great source of FTN knowledge and was a great guy to have around during those times. We started strong and ended up bickering about a lot of things... Two specific examples come to mind:

    The first is that Marc warned me about BINKP. He said that the FTS was in proposal before most popular software at the time went out of development (this was before recent MBSE updates, before Synchronet ever had a mailer, and obviously before Mystic which came before all of those).

    He specifically spoke in context of IREX which was at the time the most popular mailer. He was spot on and it was what ended up teaching me that I implement what works across all software, not what someone thinks might work (even if that someone is the "FTS").

    The second is that he gave me a good rundown of Bink 5D, and it made a lot of sense. And I read the documentation, which also seemed to agree with what he told me. When it was done, after all that effort, nothing worked. If I swapped out Mystic's tosser for FastEcho, it would fail...

    We bickered a lot about this stuff. At some level I was annoyed I spent all this time implementing and Marc was confident he knew how it was supposed to work. As it turns out we were both right, but in reality things weren't as they should have been, and documentation didn't match how software actually worked.

    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. It came at the cost of Marc and bickering and maybe ruining our own collaboration, but at least the software works. :(

    --- Mystic BBS v1.12 A48 2022/01/14 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From deon@3:633/509 to James Coyle on Wed Jan 19 13:38:15 2022
    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)
  • From Björn Felten@2:203/2 to deon on Wed Jan 19 05:18:37 2022
    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)
  • From James Coyle@1:129/215 to deon on Tue Jan 18 22:37:01 2022
    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)
  • From James Coyle@1:129/215 to Björn Felten on Tue Jan 18 23:32:03 2022
    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)
  • From Björn Felten@2:203/2 to James Coyle on Wed Jan 19 06:17:14 2022
    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)
  • From Oli@2:280/464.47 to All on Wed Jan 19 13:48:08 2022
    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)
  • From mark lewis@1:3634/12.73 to James Coyle on Wed Jan 19 08:53:06 2022

    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)
  • From mark lewis@1:3634/12.73 to Oli on Wed Jan 19 09:06:46 2022

    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)
  • From James Coyle@1:129/215 to Oli on Wed Jan 19 11:14:10 2022
    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)
  • From Oli@2:280/464.47 to mark lewis on Wed Jan 19 18:18:15 2022
    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)
  • From James Coyle@1:129/215 to Björn Felten on Wed Jan 19 12:22:23 2022
    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)
  • From James Coyle@1:129/215 to mark lewis on Wed Jan 19 12:23:38 2022
    /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)
  • From mark lewis@1:3634/12.73 to Oli on Wed Jan 19 12:57:52 2022

    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)
  • From James Coyle@1:129/215 to Oli on Wed Jan 19 13:53:14 2022
    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)
  • From Andrew Leary@1:320/219 to James Coyle on Wed Jan 19 20:52:19 2022
    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)
  • From Rob Swindell@1:103/705 to Andrew Leary on Wed Jan 19 19:58:30 2022
    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)
  • From Andrew Leary@1:320/219 to Rob Swindell on Thu Jan 20 00:39:35 2022
    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)
  • From Wilfred van Velzen@2:280/464 to Andrew Leary on Thu Jan 20 09:37:56 2022
    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)
  • From Oli@2:280/464.47 to Andrew Leary on Thu Jan 20 10:49:31 2022
    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)
  • From Oli@2:280/464.47 to Andrew Leary on Thu Jan 20 11:18:12 2022
    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)
  • From James Coyle@1:129/215 to Andrew Leary on Thu Jan 20 11:03:59 2022
    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)
  • From Rob Swindell@1:103/705 to Oli on Thu Jan 20 13:30:05 2022
    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)
  • From Oli@2:280/464.47 to Rob Swindell on Thu Jan 20 23:30:44 2022
    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)
  • From Rob Swindell@1:103/705 to Oli on Thu Jan 20 15:13:21 2022
    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)
  • From Oli@2:280/464.47 to Rob Swindell on Fri Jan 21 21:17:17 2022
    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)