You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WASI preopen option fails on Windows, but works on Linux (including Linux subsystem on Windows in the same dir).
In the simplest case, to reproduce the issue open REPL with node --experimental-wasi-unstable-preview1 in any directory and try to construct a WASI object:
@RReverser you should be able to run node ./test-wasi.js from that directory. On macOS, that works with node 13.7.0. I don't have a Windows setup at the moment, so I haven't been able to test at all on Windows and have been relying on the CI, which passes.
@himself65 do you mean node ./test-wasi.js fails on your Windows machine?
@himself65 thank you for the information. Do the same errors happen with the latest master? If so, that is concerning because the tests consistently pass on Windows (including Windows 10) in the CI.
I guess this wasn't detected by the CI because stdin isn't a TTY in the CI. I was able to get a Windows 10 environment setup, reproduced the issue, and was able to get all of the Node WASI tests passing with that patch. I also verified that the REPL example from the OP worked as expected.
Reacted by Jiawen Geng, Edward Evans and Alex Yang
It seems I encountered this issue on node 22-25"preview1".
I am compiling Go code to the wasip1/wasm target and trying to perform a recursive iteration through directories using fs.WalkDir(os.DirFS("."), "." ...). preopens: { [process.cwd()]: process.cwd() }.
On Windows 11, I get an empty filesystem, with a single empty folder process.cwd().
I would like to run this on Linux, but Windows loves breaking dual boots, so I don't have it. I had Termux handy, and to my surprise, the filesystem was not empty, and it even worked perfectly like a native binary.
I immediately realized that this is an incorrect implementation of preopens on Windows. Can I count on an investigation? Thank you.
Update
I was able to get my WASI code running on Windows using wasmtime, provided I used /c/ at the start of the path. I would like to try this with Node.js, but Node forcefully formats the path as /C:/ when using preopens: { [wd]: cwd() }, where the path manipulation logic for Windows is:
letwd=cwd()if(platform==="win32"){// This logic attempts to convert 'C:\path\to\dir' into '/c/path/to/dir'wd="/"+wd.replace(/(\w+):/,(_,disk)=>disk.toLowerCase()).replaceAll("\\","/")}
Activity
cjihrig commentedon Jan 22, 2020
Out of curiosity, do the Node WASI tests pass on your machine? We do test preopens here.
himself65 commentedon Jan 22, 2020
actually, it crashes on my Windows10 and success on Ubuntu WSL with the same node version
13.7.0🤔RReverser commentedon Jan 23, 2020
That might take some more time to set up... Or can I just run tests via locally installed Node?
cjihrig commentedon Jan 23, 2020
@RReverser you should be able to run
node ./test-wasi.jsfrom that directory. On macOS, that works with node 13.7.0. I don't have a Windows setup at the moment, so I haven't been able to test at all on Windows and have been relying on the CI, which passes.@himself65 do you mean
node ./test-wasi.jsfails on your Windows machine?himself65 commentedon Jan 23, 2020
himself65 commentedon Jan 23, 2020
node/test/wasi/test-wasi-options-validation.js
Lines 9 to 10 in 96058f3
cjihrig commentedon Jan 23, 2020
@himself65 thank you for the information. Do the same errors happen with the latest master? If so, that is concerning because the tests consistently pass on Windows (including Windows 10) in the CI.
himself65 commentedon Jan 23, 2020
same problem
allow windows to detect tty types
cjihrig commentedon Jan 24, 2020
Proposed fix in nodejs/uvwasi#92.
I guess this wasn't detected by the CI because stdin isn't a TTY in the CI. I was able to get a Windows 10 environment setup, reproduced the issue, and was able to get all of the Node WASI tests passing with that patch. I also verified that the REPL example from the OP worked as expected.
RReverser commentedon Jan 24, 2020
@cjchoi Awesome, thanks!
Does this mean it's not possible to add a regression test for this?
lundibundi commentedon Jan 24, 2020
@cjihrig @RReverser could
pseudo-ttytest perhaps suffice?richardlau commentedon Jan 24, 2020
pseudo-ttytests are skipped on Windows:node/test/pseudo-tty/testcfg.py
Lines 142 to 144 in 5bed327
allow windows to detect tty types
cjihrig commentedon Jan 24, 2020
FWIW, there is a libuv feature request for pseudo-tty support that may (or may not) help the situation in the future.
PR to fix this in Node: #31495
deps: uvwasi: cherry-pick 7b5b6f9
deps: uvwasi: cherry-pick 7b5b6f9
deps: uvwasi: cherry-pick 7b5b6f9
Mopsgamer commentedon Dec 3, 2025
It seems I encountered this issue on node 22-25
"preview1".I am compiling Go code to the
wasip1/wasmtarget and trying to perform a recursive iteration through directories usingfs.WalkDir(os.DirFS("."), "." ...).preopens: { [process.cwd()]: process.cwd() }.On Windows 11, I get an empty filesystem, with a single empty folder
process.cwd().I would like to run this on Linux, but Windows loves breaking dual boots, so I don't have it. I had Termux handy, and to my surprise, the filesystem was not empty, and it even worked perfectly like a native binary.
I immediately realized that this is an incorrect implementation of preopens on Windows. Can I count on an investigation? Thank you.
Update
I was able to get my WASI code running on Windows using
wasmtime, provided I used/c/at the start of the path. I would like to try this with Node.js, but Node forcefully formats the path as/C:/when usingpreopens: { [wd]: cwd() }, where the path manipulation logic for Windows is: