\ is a valid filename character on Linux

[king-of-poppk]

Was this overlooked?

[anodynos]

Isn't \ an escape character? Can you provide some examples?

[king-of-poppk]

touch "a\\b" or touch 'a\b'

[anodynos]

Well, it seems its a valid char indeed... this is clearly not handled & I am not sure how it should be best handled.

On Windows it's considered a path separator, hence a filename with it is converted to the unix separator.

We need to somehow decide we are coming from a Unix path and it's a normal char, and it should not be converted to a unix dir separator. But I think there is no straight forward way to determine if the \ symbol denotes a normal char in a unix filename or if it is originated from a Windows file path, therefore it's a dir separator.

I think thought it's a very rare case though, noone else has raised this issue...

Any ideas or PRs are welcome ;-)

[bmcminn]

Just my two cents: I have never seen nor expected to use \ as a filename char because that just seems outlandish and impractical to me.

I would be very curious to hear what use case this has, since even if it is a valid filename char doesn't mean it's widely used enough to support an edge case like this, and I would also be curious if \\filename is a general Unix thing that is supported in MacOS as well.

Personally, if I saw this in a code review, I'd absolutely call it into question since this seems rife for causing unintended problems down the line, whether with OS/file system portability or just filepath maintenance in the app longer term.

Additionally, POSIX path normalization via path.normalize already treats duplicate path separators path//to/file.ext as redundant and normalizes them to a single separator /.

Treating \\ differently as a filename concern in Unix vs as a path separator in Windows feels bad to me and works against the spirit of this project.

[king-of-poppk]

When you have a set A (windows paths) that is a subset of a set B (unix paths), then you can always go A -> B. If you need to be multi-platform you can restrict yourself to A, which is what this library currently does and what @bmcminn is arguing for.

There are cases where you may need to support everything that B allows (file names outside of your control, generated or not).

For A -> B you map \ to /, no problem.

For B -> A, in B you can simply treat \ as any other character, and fail when trying to convert a path than contains \ to A.

So you need a concept of "this is a path in B (where \ is not a separator)" and "this is a path in A (where \ is a separator)".

It may be more complicated than that because there may be more than just A and B.

[bmcminn]

There are some decent conversations on the topic here that go into the more general question of "which characters are valid filename chars in linux?" and that is basically anything that isn't 0x0 (NUL) or 0x2f (/). Learned a bit more about how Unix/file systems at large treat file addresses in this case.

https://unix.stackexchange.com/questions/230291/what-characters-are-valid-to-use-in-filenames
https://unix.stackexchange.com/questions/39175/understanding-unix-file-name-encoding

Though I don't think it necessarily justifies the use of \ as a worthwhile edge case to support in context of the Node ecosystem in light of Marco's comment on the valid characters in filenames thread:

Only 0x00 and 0x2f are not allowed, everything else can be used from the kernel's perspective. That doesn't mean that all applications or file systems can deal with “funny” characters. -- Marco
https://unix.stackexchange.com/questions/230291/#comment393053_230291

15+ years in software development and this just feels like a footgun waiting to happen, especially in the context of any sort of cross platform application development.

If it was supported in both Unix and Windows, then that might be a valid justification, but this seems like an esoteric code smell that could just be left out. Folx can handle an edge case like this in conjunction with this library and appending the filename in question:

let filepath = path.join(process.cwd(), '/path/to', custom_directory) + '/my\\wierd\\filename'