• spaces in filenames

    From Oli@21:3/102 to All on Sat Jan 15 19:00:05 2022
    How does Binki handle spaces in filenames? Does it escape and unescape " " and "\x20"? I couldn't find anything in the sources.

    ---
    * Origin: Birds aren't real (21:3/102)
  • From apam@21:1/182 to Oli on Sun Jan 16 09:53:00 2022
    On Sat Jan 15 19:00:00 2022, Oli wrote to All <=-

    How does Binki handle spaces in filenames? Does it escape and unescape " " and "\x20"? I couldn't find anything in the sources.

    It doesn't. I'm testing a change now to escape / unescape spaces and other reserved characters. The format is apparently \20 not \x20 for binkp

    As for \x20 - I guess this is handled by the C++ filesystem std library, i don't know.

    Andrew

    === TitanMail/freebsd v1.0.9


    --- Talisman v0.34-dev (Linux/x86_64)
    * Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)
  • From McDoob@21:4/135 to apam on Tue Jan 18 18:30:28 2022
    It doesn't. I'm testing a change now to escape / unescape spaces and
    other reserved characters. The format is apparently \20 not \x20 for
    binkp

    As for \x20 - I guess this is handled by the C++ filesystem std library,
    i don't know.

    Now that you mention it, that does remind me of C++. As I recall, '\n' was
    the LF string? I really didn't like C++, back when I was learning to code, so maybe I'm wrong.

    This was one of the reasons I chose Mystic for PiBBS. I (thought I) could
    write code for Mystic, because I have experience with (*Turbo*)Pascal...Turns out, MPL isn't exactly the same...but, still easier than learning C++!

    Never mind. Cheers!

    McDoob
    SysOp, PiBBS
    pibbs.sytes.net

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: PiBBS (21:4/135)
  • From Digital Man to apam on Wed Jan 19 00:02:22 2022
    Re: spaces in filenames
    By: apam to Oli on Sun Jan 16 2022 09:53 am

    On Sat Jan 15 19:00:00 2022, Oli wrote to All <=-

    How does Binki handle spaces in filenames? Does it escape and unescape " " and "\x20"? I couldn't find anything in the sources.

    It doesn't. I'm testing a change now to escape / unescape spaces and other reserved characters. The format is apparently \20 not \x20 for binkp

    I think it's actually supposed to be '\xXX' (and just just \x20 for space). This is what BinkIT does (for both encode and decode of filename parameters) and it appears to jive with FTS-1026.

    As for \x20 - I guess this is handled by the C++ filesystem std library, i don't know.

    Nope. '\x20' is character literal in C/C++, but that's a sequence that would be converted at compile time, not run-time, so there's no special filesystem support for that style of escape sequence. :-)
    --
    digital man (rob)

    Breaking Bad quote #38:
    Don't drink and drive, but when you do, call Saul.
    Norco, CA WX: 53.5°F, 91.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs
  • From apam@21:1/182 to Digital Man on Wed Jan 19 18:32:27 2022
    I think it's actually supposed to be '\xXX' (and just just \x20 for
    space). This is what BinkIT does (for both encode and decode of
    filename parameters) and it appears to jive with FTS-1026.

    I was going by this document:

    https://www.ritlabs.com/binkp/ (in section 5.2)

    Ah, I see. they changed the method and that is an old document. Thanks.

    Nope. '\x20' is character literal in C/C++, but that's a sequence that
    would be converted at compile time, not run-time, so there's no
    special filesystem support for that style of escape sequence. :-)

    Yeah, I thought that was a stretch. I really don't know why it worked on
    my system then :P

    Andrew

    --
    |03Andrew Pamment |08(|11apam|08)
    |13Happy|10Land |14v2.0|08!|07

    --- Talisman v0.34-dev (Linux/x86_64)
    * Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)
  • From Oli@21:3/102 to apam on Wed Jan 19 10:58:22 2022
    apam wrote (2022-01-16):

    On Sat Jan 15 19:00:00 2022, Oli wrote to All <=-

    How does Binki handle spaces in filenames? Does it escape and
    unescape " " and "\x20"? I couldn't find anything in the sources.

    It doesn't. I'm testing a change now to escape / unescape spaces and
    other reserved characters. The format is apparently \20 not \x20 for binkp

    It is \x for all reserved characters and \x20 for space (see FTS-1026). The \20 was an error in a previous FTSC proposal (FSP-1011).

    AFAIK Argus, Irex and Mystic are using or have used "\".

    binkd always used \x. mbcico, qico, Taurus/Radius, BinkIt and others use \x too.

    ---
    * Origin: Birds aren't real (21:3/102)
  • From apam@21:1/182 to Oli on Wed Jan 19 20:51:14 2022
    It is \x for all reserved characters and \x20 for space (see
    FTS-1026). The \20 was an error in a previous FTSC proposal
    (FSP-1011).

    Yep, thanks. I was looking at the wrong document.

    Andrew

    --
    |03Andrew Pamment |08(|11apam|08)
    |13Happy|10Land |14v2.0|08!|07

    --- Talisman v0.34-dev (Linux/x86_64)
    * Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)
  • From tenser@21:1/101 to Digital Man on Thu Jan 20 02:55:12 2022
    On 19 Jan 2022 at 12:02a, Digital Man pondered and said...

    I think it's actually supposed to be '\xXX' (and just just \x20 for space). This is what BinkIT does (for both encode and decode of filename parameters) and it appears to jive with FTS-1026.

    That was my reading, as well. What I took away from 1026
    is this:

    * New code should use "\xHH" for two hex-digits "HH" to represent
    "escaped" characters in commands.
    * Whitespace in filenames is prohibited at the protocol level,
    and must be escaped.
    * The character "\" must always be escaped.
    * The FSP-1011.003 escape method of "\HH" is deprecated.
    * Systems should provide a configuration option on a per-node
    basis to use the FSP-1011.003 method for nodes running software
    written assuming the "\HH" encoding.
    * Software should unconditionally transform "\20" (specifically)
    into a space character in file names.

    In other words, use "\xHH" unless directed otherwise by a
    configuration option. Always translate "\20" to space.

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Oli@21:3/102 to tenser on Wed Jan 19 15:57:13 2022
    tenser wrote (2022-01-20):

    * The FSP-1011.003 escape method of "\HH" is deprecated.

    It's not deprecated, it was never valid binkp. FSP-1011 was never released as a standard and \HH was a documentation error. (if my interpretation is correct)

    * Systems should provide a configuration option on a per-node
    basis to use the FSP-1011.003 method for nodes running software
    written assuming the "\HH" encoding.

    "It is _advised_ to have a setting for specific nodes to sent escaped characters using the incorrect method."

    advise is not a SHOULD or MUST.

    It was not the worst idea when the FTS was released, but it's not really a sufficient workaround and in many cases useless. In the source code and documentation of several mailers, only Argus and Irex are mentioned as the mailers that are victims of the error in FPS-1011. I'm not sure anyone is using Argus anymore (and it has became open source, so it could be fixed). And Irex binkp implementation is a mess anyway and might need some additional workarounds (https://gitlab.synchro.net/main/sbbs/-/issues/185).

    All other mailers I know do use \xHH or don't do any escaping at all.

    IMHO, don't waste time with implementing and documenting a configuration option. Do some hard coded auto detection for the few specific mailer versions that have problems or just ignore the few broken mailers.

    * Software should unconditionally transform "\20" (specifically)
    into a space character in file names.

    .... and send a warning message back ;)

    M_NUL BUG "Your mailer is a victim of FSP-1011. Use \x20 instead of \20."

    ---
    * Origin: Birds aren't real (21:3/102)
  • From tenser@21:1/101 to Oli on Thu Jan 20 04:52:03 2022
    On 19 Jan 2022 at 03:57p, Oli pondered and said...

    tenser wrote (2022-01-20):

    * The FSP-1011.003 escape method of "\HH" is deprecated.

    It's not deprecated, it was never valid binkp. FSP-1011 was never
    released as a standard and \HH was a documentation error. (if my interpretation is correct)

    I think you're splitting semantic hairs here. There is clearly
    software in the wild that implements the proposal's behavior;
    that behavior has been defined to be "incorrect" in an actual
    standard, but nonetheless legacy software implements it. In
    FTS-1026.003, this is described as "the incorrect method", but
    given that the dictionary definition of "deprecate" as a verb
    is to "express disapproval of" I'd say that 1026 certainly
    deprecated the proposal's mechanism. :-)

    * Systems should provide a configuration option on a per-node
    basis to use the FSP-1011.003 method for nodes running software
    written assuming the "\HH" encoding.

    "It is _advised_ to have a setting for specific nodes to sent escaped characters using the incorrect method."

    advise is not a SHOULD or MUST.

    Again, splitting semantic hairs. I did not say I was using
    the RFC terminology; my use was intended to be colloquial.

    It was not the worst idea when the FTS was released, but it's not really
    a sufficient workaround and in many cases useless. In the source code and documentation of several mailers, only Argus and Irex are mentioned as
    the mailers that are victims of the error in FPS-1011. I'm not sure
    anyone is using Argus anymore (and it has became open source, so it
    could be fixed). And Irex binkp implementation is a mess anyway and
    might need some additional workarounds (https://gitlab.synchro.net/main/sbbs/-/issues/185).

    I agree with you.

    All other mailers I know do use \xHH or don't do any escaping at all.

    If they do no escaping, they are wrong. The standard is quite
    clear about this.

    IMHO, don't waste time with implementing and documenting a configuration option. Do some hard coded auto detection for the few specific mailer versions that have problems or just ignore the few broken mailers.

    This begs the question: how does one define a "configuration
    option"? That could be a dynamic determination made when the
    connection is established based on some heuristic.

    FTS-1026.003 is very poorly written; at a minimum, it needs a
    good editor to clean up the grammar and language. My suspicion
    is that the "configuration option" bit wasn't meant to be
    strictly literal, but rather, that the intent be some mechanism
    for dealing with software written to the proposal's recommendation,
    as a pragmatic consideration. Whether that was done with some
    file or done with some other mechanism seems largely irrelevant
    from the intent.

    * Software should unconditionally transform "\20" (specifically)
    into a space character in file names.

    .... and send a warning message back ;)

    M_NUL BUG "Your mailer is a victim of FSP-1011. Use \x20 instead of \20."

    Let's be honest: most BBS people would have no idea what to do
    with that and would just ignore it.

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)