Stream: git-wasmtime

Topic: wasmtime / issue #1358 Decide on dangling symlink semanti...

Wasmtime GitHub notifications bot (Sep 24 2026 at 16:31):

fitzgen closed issue #1358:

Windows distinguishes between file symlinks and directory symlinks. It's possible to create a dangling symlink, but the type (file/directory) has to be specified upfront, upon creation.

The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:

* under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
* under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid
* under Windows Explorer, the dangling symlink is invisible

We should decide how WASI should handle a request to create a dangling symlink. Possible ideas:

1. default to file symlinks, make sure that WASI can correctly handle them even in case of type mismatch and neglect the fact that they may be broken outside WASI
2. as in 1., but correct the symlinks when encountered/upon close/etc.
3. deny creating dangling symlinks altogether and modify the tests to disallow it (it may break existing code! so probably a bad idea)

cc @kubkon @sunfishcode @peterhuene

Wasmtime GitHub notifications bot (Sep 24 2026 at 16:31):

fitzgen commented on issue #1358:

WASI semantics are part of the WASI spec which has not been part of this repo for a long time, reopen on the WASI standard repo if still an issue.

Last updated: Oct 11 2026 at 04:10 UTC