std: Update documentation of seek_write on Windows #120452
Merged
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
Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in rust-lang#35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states: > If Length and ByteOffset specify a write operation past the current > end-of-file mark, NtWriteFile automatically extends the file and updates > the end-of-file mark; any bytes that are not explicitly written between > such old and new end-of-file marks are defined to be zero. This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
|
r? @m-ou-se (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
O-windows
alexcrichton
added a commit
to alexcrichton/system-interface
that referenced
this pull request
Jan 28, 2024
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.
|
Hm, the move to That said, I'm pretty sure Which is a long winded way of saying I'll probably accept this but I'd want to check in with a few people first. |
|
I am told that, yes, @bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 30, 2024
…llaumeGomez Rollup of 18 pull requests Successful merges: - rust-lang#119123 (Add triagebot mentions entry for simd intrinsics) - rust-lang#119991 (Reject infinitely-sized reads from io::Repeat) - rust-lang#120172 (bootstrap: add more unit tests) - rust-lang#120250 (rustdoc: Prevent JS injection from localStorage) - rust-lang#120376 (Update codegen test for LLVM 18) - rust-lang#120387 (interpret/memory: fix safety comment for large array memset optimization) - rust-lang#120400 (Bound errors span label cleanup) - rust-lang#120402 (Make the coroutine def id of an async closure the child of the closure def id) - rust-lang#120403 (Add instructions of how to use pre-vendored 'rustc-src') - rust-lang#120424 (raw pointer metadata API: data address -> data pointer) - rust-lang#120425 (Remove unnecessary unit returns in query declarations) - rust-lang#120439 (Move UI issue tests to subdirectories) - rust-lang#120443 (Fixes footnote handling in rustdoc) - rust-lang#120452 (std: Update documentation of seek_write on Windows) - rust-lang#120460 (Be more careful about interpreting a label/lifetime as a mistyped char literal.) - rust-lang#120464 (Add matthewjasper to some review groups) - rust-lang#120467 (Update books) - rust-lang#120488 (Diagnostic lifetimes cleanups) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 30, 2024
Rollup merge of rust-lang#120452 - alexcrichton:update-windows-seek-write-docs, r=ChrisDenton std: Update documentation of seek_write on Windows Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in rust-lang#35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states: > If Length and ByteOffset specify a write operation past the current > end-of-file mark, NtWriteFile automatically extends the file and updates > the end-of-file mark; any bytes that are not explicitly written between > such old and new end-of-file marks are defined to be zero. This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
sunfishcode
pushed a commit
to bytecodealliance/system-interface
that referenced
this pull request
Feb 13, 2024
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.
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.
Currently the documentation of
FileExt::seek_writeon Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in #35704 (wow blast from the past!). At the time the functionality here was implemented usingWriteFile, but nowadays theNtWriteFilemethod is used instead. The documentation forNtWriteFileexplicitly states:This commentary has had a downstream impact in the
system-interfacecrate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.