bpo-42606: Support POSIX atomicity guarantee of O_APPEND on Windows

[izbyshev]

On POSIX-conforming systems, O_APPEND flag for open() must ensure
that no intervening file modification occurs between changing the file
offset and the write operation[1]. In effect, two processes that
independently opened the same file with O_APPEND can't overwrite
each other's data. On Windows, however, the Microsoft C runtime
implements O_APPEND as an lseek(fd, 0, SEEK_END) followed by write(),
which obviously doesn't provide the above guarantee. This affects
both os.open() and the builtin open() Python functions, which rely on
_wopen() from MSVCRT.

One way to achieve the desired behavior is to ensure that the Windows
handle backing the MSVCRT file descriptor has FILE_APPEND_DATA access
right, but doesn't have FILE_WRITE_DATA. This makes the Windows kernel
enforce the described semantics.

To avoid full reimplementation of _wopen(), implement the above by
duplicating the MSVCRT-created handle with fixed up access rights and
wrapping it with a new file descriptor. Note that handles created by
functions like os.dup() will still have the correct access rights (and
thus atomic behavior) because MSVCRT duplicates them with
DUPLICATE_SAME_ACCESS flag.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html

https://bugs.python.org/issue42606

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[xhyrom]

Why this has not been review since 2020?

[github-actions]

This PR is stale because it has been open for 30 days with no activity.