[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> added the comment:

> os.write(fd) can't ... know that the fd was opened with O_APPEND

It's possible to query the granted access of a kernel handle via NtQueryObject: ObjectBasicInformation -- not that I'm suggesting to use it.

> the most serious one is rather silly: we need to honor the current 
> umask to possibly create a read-only file, 

It pains me to see umask get in the way of implementing open() directly via CreateFileW, which we need in order to support delete-access sharing. 

Python could implement its own umask value in Windows. os.umask() would set the C umask value as well, but only for the sake of consistency with C extensions and embedding.

> os module exposes some MSVCRT-specific flags for use with os.open() 
> (like O_TEMPORARY), which a reimplementation would have to support. 

Additionally, ucrt has an undocumented O_OBTAIN_DIR flag. It opens with backup semantics, which would be more obvious if aliased as O_BACKUP_SEMANTICS. This allows an open to take advantage of SeBackupPrivilege and SeRestorePrivilege if they're enabled, to get read or write access regardless of the file security.

Open attribute flags could also be supported, such as O_ATTR_HIDDEN and O_ATTR_SYSTEM. These are needed because a hidden or system file is required to remain as such when it's overwritten, else CreateFileW fails.

> It seems easy in most cases, but there is O_TEXT, 

Retaining O_TEXT in 3.x was probably an accident. Text mode should use a TextIOWrapper instance, and I doubt that there's a serious need to support Ctrl+Z as EOF. 

If it's important enough, msvcrt.open() and msvcrt.O_TEXT could be provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42606>
_______________________________________