Observe close(2) errors for std::fs::{copy, write}

[tbu-]

Adds a (private to std) File::close method and uses it in std::fs::write and std::fs::copy.

This is a lighter version of rust-lang/libs-team#705 that can be added even if that ACP isn't accepted, as this is purely a quality of implementation thing that could be reverted at any time. External libraries and applications can use external crates like https://crates.io/crates/close-err to achieve the same with the files they own.

CC rust-lang/libs-team#705.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tbu-]

Even though this can't fail, I copied it for symmetry with the other implementations.

[the8472]

std::fs::{copy, write} are convenience methods, that do nothing about durability. They'll also happily truncate existing files and then leaving you stranded in the middle of the operation if something goes wrong. They don't do the rename dance, they don't use tempfiles, they don't fsync. Basically, if one is using them then one is signalling not caring much.

So I don't see why these practically least-effort methods are the ones that would warrant extra care.

Such a PR might be more appropriate to atomic write crates... except that they already do fsync, which subsumes this.

• https://github.com/untitaker/rust-atomicwrites/blob/c1b223ad040939501df1a98aeaf19f86f49a7302/src/lib.rs#L200-L203
• https://docs.rs/atomic-write-file/0.3.0/atomic_write_file/index.html#how-it-works).](https://docs.rs/atomic-write-file/0.3.0/atomic_write_file/index.html#how-it-works

[tbu-]

We're just returning the error from close(2) that we're calling anyway. I'm just changing the code from ignoring the error to returning it. Why is that such a problem? The OS is telling us something, and you'd prefer to throw the error away over returning it to the user?

[the8472]

Well, I both do not like the precedent, and I also think that if anything really needs to do this then these are the methods where it's the least necessary, which makes the first point worse "look, even these simple, least-defensive std methods do it!"