Path logic broken with NODERAWFS on Windows

[stevenwdv]

On Windows with NODERAWFS, directory separators are \ and paths start with \\ or a drive letter. However, the stdlib assumes Unix paths. This means most operations on paths don't work correctly.

For example:

#include <filesystem>
#include <iostream>

int main() {
  std::filesystem::path p = R"(C:\Users\me)";
  std::clog << p.parent_path() << '\n';
  std::clog << p.root_path() << '\n';
  std::clog << std::boolalpha << p.is_absolute() << '\n';
  std::clog << absolute(p) << '\n';
}

Under Emscripten with NODERAWFS on Windows:

""
""
false
"C:\\current\\directory/C:\\Users\\me"

Expected/regular outcome on Windows:

"C:\\Users"
"C:\\"
true
"C:\\Users\\me"

Related to: #25291, #17829.

This means that for us, NODERAWFS is not usable on Windows (see e.g. #25291 (comment)). However, I understand this may be hard to fix, and a.t.m. we don't really need it per se.

Version: Emscripten 6.0.9 + fix for #25291.

[sbc100]

It seems like we have a couple of possible ways to fix this:

1. Normalize pathnames in NODERAWFS so that only forward slashes a visible the Wasm module
2. Modify libc++ such that the pathname separator is somehow runtime configurable.

Neither of these sound particularly simple to me.

Is windows support for NODERAWFS particularly important to a use case you have?

[guybedford]

(1) does seem like it could be worthwhile to me, since Windows support is one of the Node.js guarantees. Normalizing paths to start with // can also be useful for aligning absolute pathing checks.

[sbc100]

Even if we do (1) we there are still a bunch of issues we would not be solved. For example:

1. Pathnames that arrive via some other mechanism (e.g. reading from a file, environment variables, user input
2. libc and libc++ notion of is_absolute would need to be modified to include drive letter support.

[guybedford]

I guess the alternative is to explicitly detect if the environment is Windows from Node.js itself, and then change the implementation of FS functions accordingly to support Windows absolute path forms and both separators.

[sbc100]

Yes, that is option (2) above essentially. Have some kind of runtime function to determining windows vs not-windows behaviour.

[guybedford]

Yes, branching on process.platform in Node.js would be fairly idiomatic.

[sbc100]

Right, but there is a lot C/C++ code out there (in particular libc and libc++ that assume) that assume e.g. IS_WINDOWS is a build-time configuration. And musl itself has no concept (even at build time) of anything like windows (since its a linux-specific project).

In other words, I don't think this is going to be a small fix.