Implement read_offset and write_offset
#35704
Conversation
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
sfackler
added
the
T-libs-api
| @@ -348,6 +348,18 @@ impl File { | |||
| inner: self.inner.duplicate()? | |||
| }) | |||
| } | |||
|
|
|||
| /// Reads a number of bytes starting from a given offset. | |||
There was a problem hiding this comment.
It's specifically an offset from the start of the file, not the current cursor position, right? Could you add that to the docs?
|
Can you also be sure to add tests for this? Especially with how it relates to the "current file pointer" and such |
|
Added docs and tests. |
|
Discussed during @rust-lang/libs triage today the conclusion was that we probably want to call these Could you also file a tracking issue and update the tracking issue here? |
|
Done. |
|
@bors r+ 4e48924 |
Implement `read_offset` and `write_offset` These functions allow to read from and write to a file from multiple threads without changing the per-file cursor, avoiding the race between the seek and the read.
Implement `read_offset` and `write_offset` These functions allow to read from and write to a file from multiple threads without changing the per-file cursor, avoiding the race between the seek and the read.
|
⌛ Testing commit 4e48924 with merge 6ba6e27... |
|
💔 Test failed - auto-linux-64-cross-freebsd |
|
@bors retry |
|
⌛ Testing commit 4e48924 with merge 2d35fe1... |
|
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
|
This failure is definitely my fault. |
|
@alexcrichton New situation, the Windows version of this differs from the Unix one: Do we still want this and document the difference between platforms? I don't see a way to emulate either platform's behavior on the other one atomically (atomicity is what this function is about). |
|
That seems like a pretty significant platform difference. :( |
|
Yeah that seems significant enough that we wouldn't provide a cross platform API for this. Perhaps a platform-specific one in |
|
@tbu- my understanding of the Windows API is that it would be possible to avoid the update of the file pointer if the file had been opened with the flag Would it be acceptable to only allow |
|
@ranma42 do we have a way to open files with |
|
@arthurprs Right now the This is already used in the stdlib to open pipes as overlapped files: rust/src/libstd/sys/windows/pipe.rs Line 97 in e77d86c |
|
Lints should be the last stage before tests, fixed. |
|
@bors: r+ |
|
📌 Commit 744aecf has been approved by |
|
⌛ Testing commit 744aecf with merge 2481c23... |
|
💔 Test failed - auto-linux-64-x-android-t |
|
It seems the signature of Is |
|
IIRC it's because this is an older version of Android compatibility. I think newer versions changed the definition of |
|
I changed it to only look for |
|
@bors: r+ |
|
📌 Commit 94aa08b has been approved by |
Implement `read_offset` and `write_offset` These functions allow to read from and write to a file from multiple threads without changing the per-file cursor, avoiding the race between the seek and the read.
|
💔 Test failed - auto-linux-64-x-android-t |
|
@bors: r+ |
|
📌 Commit 1554993 has been approved by |
|
⌛ Testing commit 1554993 with merge e1b6777... |
Implement `read_offset` and `write_offset` These functions allow to read from and write to a file from multiple threads without changing the per-file cursor, avoiding the race between the seek and the read.
|
Finally! Thanks for your patience, @alexcrichton. |
|
Test. |
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.
…rite-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.
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.
These functions allow to read from and write to a file from multiple
threads without changing the per-file cursor, avoiding the race between
the seek and the read.