Simplify some filesystem extensions on Windows #43
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit it borne out of CI failures on bytecodealliance/wasmtime#7638. Investigating this failure has revealed a number of aspects here which I've attempted to address in this PR. The notable changes here are: * The current code in this crate was handling the case where `FileExt::seek_write` on Windows was leaving intermediate bytes as undefined when a write happened beyond the end of a file. I believe that this is due to an error in the documentation of the Rust standard library which I've submitted rust-lang/rust#120452 to fix. * Removing handling of "always write zeros" handles the primary failure of the PR bytecodealliance/wasmtime#7638 which is that `write_vectored_at` was always returning 0 on Windows for writes past the end of the file. This is because Windows doesn't have a vectored file write so the vector chosen was the first nonempty vector which was the one containing zeros to extend the file. That meant that the method always returned zero. * Previously the methods here used file locking which appeared to handle the case where the file was calculated and then the write happened. Given that this no longer happens I've removed the locking here. * The `write_all_at` method had a loop around `reopen_write` handling the `Interrupted` error but no other methods did, so I opted to remove the loop and leave that to the internals of `reopen_write` if necessary. * Other methods related to this are all simplified to directly use `seek_write` and avoid handling the case where writes past the end need to write zeros (as zeros are guaranteed by Windows). Overall my hope is to use this to unblock bytecodealliance/wasmtime#7638 to get more platform-agnostic behavior for writing beyond the end of a file.
|
I can confirm as well that with this PR bytecodealliance/wasmtime#7638 passes tests |
|
@sunfishcode mind if I ping you on this? |
sunfishcode
approved these changes
Feb 13, 2024
|
This is now released in system-interface 0.27.1. |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit it borne out of CI failures on bytecodealliance/wasmtime#7638. Investigating this failure has revealed a number of aspects here which I've attempted to address in this PR. The notable changes here are:
The current code in this crate was handling the case where
FileExt::seek_writeon Windows was leaving intermediate bytes as undefined when a write happened beyond the end of a file. I believe that this is due to an error in the documentation of the Rust standard library which I've submitted std: Update documentation of seek_write on Windows rust-lang/rust#120452 to fix.Removing handling of "always write zeros" handles the primary failure of the PR Discard 0-sized writes to files wasmtime#7638 which is that
write_vectored_atwas always returning 0 on Windows for writes past the end of the file. This is because Windows doesn't have a vectored file write so the vector chosen was the first nonempty vector which was the one containing zeros to extend the file. That meant that the method always returned zero.Previously the methods here used file locking which appeared to handle the case where the file was calculated and then the write happened. Given that this no longer happens I've removed the locking here.
The
write_all_atmethod had a loop aroundreopen_writehandling theInterruptederror but no other methods did, so I opted to remove the loop and leave that to the internals ofreopen_writeif necessary.Other methods related to this are all simplified to directly use
seek_writeand avoid handling the case where writes past the end need to write zeros (as zeros are guaranteed by Windows).Overall my hope is to use this to unblock bytecodealliance/wasmtime#7638 to get more platform-agnostic behavior for writing beyond the end of a file.