Skip to content

[WasmFS] Fix absolute path access under NODERAWFS#24733

Open
kleisauke wants to merge 7 commits intoemscripten-core:mainfrom
kleisauke:wasmfs-noderawfs-abspath
Open

[WasmFS] Fix absolute path access under NODERAWFS#24733
kleisauke wants to merge 7 commits intoemscripten-core:mainfrom
kleisauke:wasmfs-noderawfs-abspath

Conversation

@kleisauke
Copy link
Copy Markdown
Collaborator

@kleisauke kleisauke commented Jul 17, 2025

Resolves: #24830.
Supersedes: #24833.

kleisauke added a commit to kleisauke/wasm-vips that referenced this pull request Jul 18, 2025
@kleisauke kleisauke force-pushed the wasmfs-noderawfs-abspath branch from 539e100 to 4c2d596 Compare March 23, 2026 18:06
@kleisauke kleisauke changed the title [WasmFS] Add testcases for absolute path handling with NODERAWFS [WasmFS] Fix absolute path access under NODERAWFS Mar 23, 2026
@kleisauke kleisauke force-pushed the wasmfs-noderawfs-abspath branch 4 times, most recently from 99a1e0d to fd7f0a9 Compare March 24, 2026 12:17
kleisauke added a commit to kleisauke/wasm-vips that referenced this pull request Mar 24, 2026
@kleisauke
Copy link
Copy Markdown
Collaborator Author

kleisauke commented Mar 24, 2026

Marking as ready for review with a few caveats:

@kleisauke kleisauke marked this pull request as ready for review March 24, 2026 16:03
kleisauke added a commit to kleisauke/wasm-vips that referenced this pull request Mar 25, 2026
@kleisauke
Copy link
Copy Markdown
Collaborator Author

The Windows CI issue was caused due to the temporary directory being located on C:\ while the current working directory was on D:\, which broke WasmFS's single-root (/) assumption.

This has been fixed in commit d364aeb, which also appears to resolve the test failure in wasmfs.test_readdir_rawfs.

Comment on lines +77 to +78
if (!root->getBackend()->isVirtualized()) {
return {std::make_pair(std::move(curr), path)};
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole point of virtualization is that a virtual backend looks the same as a "real" backend. Can we get away without this part of the change?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, this change was related to -sNODERAWFS on Windows, which doesn't have a single-root directory

I initially attempted a different fix (see e.g. the changes before commit d364aeb), but it failed when the current working directory and the absolute path to be accessed were on different drives, see comment #24733 (comment).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed this isVirtualized() check with a requiresPathTraversal() check via commit cb9bb3e.

Comment on lines +112 to +114
if (!rootBackend->isVirtualized()) {
return rootDirectory;
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use a more precise overridable hook here, e.g. shouldMountSpecialFiles, rather than checking whether the backend is virtual.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just separated this change to PR #26607.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all the changes here just cleanups that are not directly related to the absolute path access problem?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I've just separated these changes into individual PRs.


addToLibrary({
$wasmfsNodeIsWindows: !!process.platform.match(/^win/),
#if !ENVIRONMENT_MAY_BE_NODE
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the goal of this change?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was to allow a single Wasm binary to run both on Node.js and on the web (if you build with -sWASMFS -sNODERAWFS the Wasm binary is restricted to Node.js only).

I reverted this (and its test case) with commit ff4bba2. A PR will be opened for this later.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... I just opened PR #26608 for this change.

@kleisauke kleisauke force-pushed the wasmfs-noderawfs-abspath branch 2 times, most recently from b1edba4 to 4f20a95 Compare April 2, 2026 08:41
sbc100 pushed a commit that referenced this pull request Apr 2, 2026
Split out from #24733, this fixes a test failure in
`other.test_fs_dev_random_wasmfs_rawfs` from that PR.
sbc100 pushed a commit that referenced this pull request Apr 2, 2026
See commit 48459c6 for details.

Split out from #24733, this fixes a test failure in
`core0.test_fs_js_api_wasmfs_rawfs` from that PR.
Copy link
Copy Markdown
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for splitting this up. It's much more focused and easier to review now. Mostly LGTM, with some bikeshedding and a correctness concern.

WASMFS_UNREACHABLE("TODO: implement NodeBackend::createSymlink");
}

virtual bool requiresPathTraversal() override {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about calling this usesRawPaths? (And flipping the result, of course.) I think that's slightly easier to understand than requiresPathTraversal, though it's not perfect.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think usesRawPaths it's too implementation-specific. How about requiresPathResolution? See commit e21bc63.

// full path directly. In that case, skip WasmFS path parsing and pass the
// path through unchanged.
if (!root->getBackend()->requiresPathTraversal()) {
return {std::make_pair(std::move(curr), path)};
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this going to cause WasmFS to model the underlying file system as completely flat, so that there is a single mount directory directly containing every file ever opened, no matter how deep that file is in the underlying directory structure?

If so, is that going to cause problems with reading directory entries?

Copy link
Copy Markdown
Collaborator Author

@kleisauke kleisauke Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, this is going to break in such situations as it implicitly assumes that the entire file system behaves like the root backend.

Commit e21bc63 changes this to curr->getBackend() instead, which allows:

$ tree / -L 2 --dirsfirst
/ (MEMFS)
├── dev
│   ├── null -> SpecialFiles::getNull()
│   ├── random -> SpecialFiles::getRandom()
│   ├── stderr -> SpecialFiles::getStderr()
│   ├── stdin -> SpecialFiles::getStdin()
│   ├── stdout -> SpecialFiles::getStdout()
│   └── urandom -> SpecialFiles::getURandom()
├── tmp
└── host (NODERAWFS)

(i.e. the Node filesystem is mounted under /host, while the wasmfs_create_root_dir() hook is not overriden)

kleisauke added a commit that referenced this pull request Apr 4, 2026
kleisauke added a commit that referenced this pull request Apr 4, 2026
Previously, the WasmFS Node backend assumed Node.js was always
available. This change allows building binaries that include Node
backend stubs, so they can run in web environments.

Split out from #24733.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WasmFS NodeRawFS is not consistent with NodeRawFS (non-WasmFS version)

2 participants