Stream: git-wasmtime

Topic: wasmtime / Issue #1725 Revert fstatat on *nix and test sy...

Wasmtime GitHub notifications bot (May 19 2020 at 16:14):

github-actions[bot] commented on Issue #1725:

Subscribe to Label Action

cc @kubkon

<details>
This issue or pull request has been labeled: "wasi"

Thus the following users have been cc'd because of the following labels:

• kubkon: wasi

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (May 19 2020 at 16:25):

kubkon commented on Issue #1725:

@sunfishcode OK, this should now be it for *nixes. However, I see that symlink resolution fails on Windows, and I'll need to investigate whether this is something new, or whether this bug was already there in the past but we missed it due to lack of testing.

Wasmtime GitHub notifications bot (May 19 2020 at 16:28):

kubkon commented on Issue #1725:

@sunfishcode OK, this should now be it for *nixes. However, I see that symlink resolution fails on Windows, and I'll need to investigate whether this is something new, or whether this bug was already there in the past but we missed it due to lack of testing.

Oh, it seems I applied the wrong fillers into windows::path::path_filestat_{get, set_times} that's why it's failing.

Wasmtime GitHub notifications bot (May 20 2020 at 16:32):

kubkon commented on Issue #1725:

@sunfishcode I've now found and fixed the bug on Windows. It turns out that you need to pass a special flag to stop Windows from automatically dereferencing a symlink when creating a handle for it. In essence, File::open("/dir/symlink") or equivalently OpenOptions::new().read(true).open("/dir/symlink") is not enough and will cause Windows to create a handle for the target "/dir/file". To prevent Windows from doing so, we need to pass FILE_FLAG_NO_REPARSE_POINT to OpenOptions::custom_flags which will stop Windows from deref and will allow us to properly mine the file stat from the actual symlink and not the target.

Wasmtime GitHub notifications bot (May 20 2020 at 16:33):

kubkon edited a comment on Issue #1725:

@sunfishcode I've now found and fixed the bug on Windows. It turns out that you need to pass a special flag to stop Windows from automatically dereferencing a symlink when creating a handle for it. In essence, File::open("/dir/symlink") or equivalently OpenOptions::new().read(true).open("/dir/symlink") is not enough and will cause Windows to create a handle for the target "/dir/file". To prevent Windows from doing so, we need to pass FILE_FLAG_NO_REPARSE_POINT to OpenOptions::custom_flags which will stop Windows from deref and will allow us to properly mine the file stat from the actual symlink and not the target.

Oh and it turns out we've had this bug all along, but didn't catch it as we didn't test for symlinks in path_filestat tests ;-}

Wasmtime GitHub notifications bot (May 20 2020 at 16:33):

kubkon edited a comment on Issue #1725:

@sunfishcode I've now found and fixed the bug on Windows. It turns out that you need to pass a special flag to stop Windows from automatically dereferencing a symlink when creating a handle for it. In essence, File::open("/dir/symlink") or equivalently OpenOptions::new().read(true).open("/dir/symlink") is not enough and will cause Windows to create a handle for the target "/dir/file". To prevent Windows from doing so, we need to pass FILE_FLAG_OPEN_REPARSE_POINT to OpenOptions::custom_flags which will stop Windows from deref and will allow us to properly mine the file stat from the actual symlink and not the target.

Oh and it turns out we've had this bug all along, but didn't catch it as we didn't test for symlinks in path_filestat tests ;-}

Wasmtime GitHub notifications bot (May 20 2020 at 16:35):

kubkon commented on Issue #1725:

Oh and I guess we should reapply this fact to other syscalls targeting Windows which deref symlinks, but I guess in another PR.

Last updated: Nov 22 2024 at 16:03 UTC