Change:
/// use std::os::unix::prelude::FileExt; /// /// fn main() -> io::Result<()> { <del> ///     let file = File::open("foo.txt")?; </del> <ins> ///     let file = File::create("foo.txt")?; </ins> /// ///     // We now write at the offset 10. ///     file.write_at(b"sushi", 10)?;

Discussion:
<!-- the function from doesn't work as described and the example fails --I'm pretty new to rust and I'm working on a small project where I need to write into a file some data at various offsets, so the function seems to perfectly fit my need. So I tried this code (with is the provided example): and I do I expected to see this happen: a in the current directory with a size of 15 bytes Instead, this happened: Error: Os { code: 2, kind: NotFound, message: "No such file or directory" } So, I modifed the filename to (in order to have an absolute path). I got the same error. So, I created the file with Then I got the error: So, I add the line to get some info on the file Then I got: So, the file is open read-only, I searched and modified the code to: Then I got: and finally no error (on stdout), But the file is only 5-byte long whereas I expected it to be 15-byte long. And checking content with gives: The final code is and you need to manually create the file before running the binary. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Wow those docs are terrible, how did that happen? We can immediately patch the docs to code that actually would work to write to a file, but we need to define what "extended appropriately" means. i.e. Is this intended behavior? But perhaps more importantly, we need to figure out why the hell we have doctest examples that don't actually work and what can we do to fix that?
Yeah it's weird that we have a non-working example. That should be fixed asap. It looks like it was copy/pasted from but not updated to use or something like that. I'll mark this as help wanted. Fixing that should not be controversial.

The issue with the final code in the OP is that it opens the file in append only mode. The docs do not cover this case at all so I can't say what the intended behaviour is. I guess is really incompatible with append only because it needs to have some knowledge of the real file position in order to work as expected.
( for the doc fix part, anyways. )
It does explain that returning short writes is valid, so I guess the behavior exhibited in the append-only case presented here is technically acceptable behavior.
On Linux, just calls which documents this:
There was a to fix this via a flag on , but that didn't get merged...
We discussed this in the libs-api meeting. It seems that there are 2 actionable items here, both in the documentation: The example in needs to be fixed to use (write mode) instead of (read mode). The documentation for should link to to indicate that, on some platforms, files opened in append mode ignore the position passed in and always append to the end of the file.
claim