Steve Dower added the comment:
> This change has been discussed, but I don't know whether or not it's just a
> pipe dream
Still a bit of a pipe dream, but I'll add this issue as something that would be
fixed by it (to stack up against the list of things that would be broken...)
--
Eryk Sun added the comment:
There's nothing we could easily change to use the native OS append mode or
support inheritance of file descriptors in subprocess. A general solution would
be to give up on C file descriptors and CRT functions such as _wopen(), read(),
etc, and instead implement ou
wolfgang kuehn added the comment:
The second alternative (wrapping the OS handle in a file descriptor) works like
a charm, and is the less invasive workaround code-wise.
Thanks for the magic, which I must respect as such :-)
Still I feel that this is a bug since (a) it shows an unexpected be
Eryk Sun added the comment:
In Windows, the C runtime's append mode doesn't use the native file append
mode. The CRT just opens the file in read-write mode and seeks to the end,
initially and before each write.
subprocess.Popen() doesn't implement inheritance of file descriptors, so the
CR
New submission from wolfgang kuehn :
On Windows, if you pass an existing file object in append mode to a subprocess,
the subprocess does **not** really append to the file:
1. A file object with `Hello World` content is passed to the subprocess
2. The content is erased
3. The subprocess writes
