Fix #10981 - Wrong usage of the write() system call in std.file.write() and in std.file.copy()

[vindexbit]

For the write system call (as with read), it is normal behavior to return fewer bytes than requested.

A more serious issue was found in std.file.copy:

cenforce(
    core.sys.posix.unistd.read(fdr, buf, toxfer) == toxfer
    && core.sys.posix.unistd.write(fdw, buf, toxfer) == toxfer,
    f, fromz);

The problem here is that an error may occur during the write call (for example, ENOSPC), but the programmer receives no information about it. Moreover, in my case, I encountered a phantom ENOENT error reported for the source file, which is clearly incorrect.

The behavior of the function has now been significantly improved.

[dlang-bot]

Thanks for your pull request and interest in making D better, @vindexbit! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#10982"

[thewilsonator]

signed/unsigned comparison here

[CyberShadow]

Moot because we never read more than BUFSIZ? Or does the compiler complain?

[vindexbit]

In this context, it doesn't matter. The rr variable cannot be less than zero. And the wrAcc variable should logically never be less than zero, so size_t.