Looks like this perhaps requires a wasmfs change to match? wasmfs.test_fs_nodefs_readdir is now failing. Looks like maybe wasmfs is reporting "." and ".." but the old FS is not ? Maybe we want go back to the old way of verifying the results to avoid having to fix these decrpencies as part of this PR?

Yeah maybe the best thing to do would be to grab the output and make a series of assertions that it contains or does not contain certain strings? It seems that the order is not stable but the set of lines should be.

Yeah maybe the best thing to do would be to grab the output and make a series of assertions that it contains or does not contain certain strings? It seems that the order is not stable but the set of lines should be.

Sure. That sounds reasonable. I was a little surprised to see who different the wasmfs output was though. I guess there is stuff we need to address there:

--- expected
+++ actual
@@ -1,12 +1,13 @@
 listing contents of dir=/
 .
 ..
+dev
 tmp
-home
-dev
-proc
 listing contents of dir=/working
+.
+..
 existing
+named_pipe
 stdout
 test_nodefs_readdir.js
 test_nodefs_readdir.wasm

Specifically it looks like wasmfs supports . and .. but the old FS doesn't? Also, the home and proc directories should match too. These are all separate issues though.

Rebasing could fix the code size failures.

Looks like the wasm2js failure is real. Might be worth switching to assertions rather then comparing output verbatim?

@sbc100 can this be merged? Only test failure is test_nodejs_sockets_echo_subprotocol which looks to me like a flake.

This change (at least I suspect it's this change) seems to be failing on Windows:
https://ci.chromium.org/ui/p/emscripten-releases/builders/try/win/b8729460472173187201/overview
Is that expected? Should we disable it there?

I think that may be caused by #23025? Looks more related to that than to this one.

Can you make a followup to #23025 that marks test_fs_enotdir as @crossplatform?