Skip to content

Conversation

@dicej
Copy link
Contributor

@dicej dicej commented Jun 26, 2024

When an application attempts to open a non-existent path such as //foo/bar/baz on Windows, Node generates an error of the form:

{
  errno: -4094,
  syscall: 'open',
  code: 'UNKNOWN',
  path: '//foo/bar/baz'
}

Prior to this commit, that error would be re-thrown, causing Wasm execution to trap. Now we convert it to a "no-such-device" error instead.

When an application attempts to open a non-existent path such as `//foo/bar/baz`
on Windows, Node generates an error of the form:

```
{
  errno: -4094,
  syscall: 'open',
  code: 'UNKNOWN',
  path: '//foo/bar/baz'
}
```

Prior to this commit, that error would be re-thrown, causing Wasm execution to
trap.  Now we convert it to a "no-such-device" error instead.

Signed-off-by: Joel Dice <[email protected]>
@dicej dicej force-pushed the windows-no-such-device branch from 0fdd543 to 5d3336e Compare June 26, 2024 15:37
@guybedford guybedford merged commit 90154c3 into bytecodealliance:main Jun 26, 2024
@dicej
Copy link
Contributor Author

dicej commented Jun 26, 2024

Thanks for merging this, @guybedford. Is there a chance we could publish a new release of the shim with this fix soonish? That would help unblock dotnet/runtimelab#2614, which is where I encountered this issue.

@guybedford
Copy link
Collaborator

Sure, I've pushed a 0.16.3.

@oovm
Copy link

oovm commented Jan 29, 2025

This fix was a bit confusing to me, and it took me a while to find the real reason.

On Windows, the path emitted by std::fs::read will be prefixed with \\\\C:\, but node cannot recognize such a path, node open only supports C:\

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.

3 participants