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>
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.
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.
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 equivalentlyOpenOptions::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 passFILE_FLAG_NO_REPARSE_POINT
toOpenOptions::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.
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 equivalentlyOpenOptions::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 passFILE_FLAG_NO_REPARSE_POINT
toOpenOptions::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 ;-}
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 equivalentlyOpenOptions::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 passFILE_FLAG_OPEN_REPARSE_POINT
toOpenOptions::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 ;-}
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: Dec 23 2024 at 13:07 UTC