Stream: git-wasmtime

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

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2020 at 19:49):

marmistrz opened 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

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2020 at 19:49):

marmistrz labeled 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

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2020 at 19:49):

marmistrz labeled 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

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2020 at 19:49):

marmistrz labeled 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

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2020 at 20:13):

peterhuene commented on Issue #1358:

I think I'm leaning towards a preference to default to a file symlink and document that (Windows-specific) behavior.

Last updated: Dec 23 2024 at 12:05 UTC