[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Eryk Sun added the comment: > So the idea is to delete the file for a brief period, but then > undelete it. Currently NTFS defaults to using classic delete semantics for delete-on-close. However, it supports POSIX delete semantics for delete-on-close, so the default could change in a

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > I think truncation via TRUNCATE_EXISTING (O_TRUNC, with O_WRONLY or O_RDWR) > or overwriting with CREATE_ALWAYS (O_CREAT | O_TRUNC) is at least tolerable > because the caller doesn't care about the existing data. Yes, I had a thought that creating or

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Eryk Sun added the comment: > I've found a catch via ProcessHacker: CreateFile() with > GENERIC_WRITE (or FILE_GENERIC_WRITE) additionally grants > FILE_READ_ATTRIBUTES for some reason. CreateFileW always requests at least SYNCHRONIZE and FILE_READ_ATTRIBUTES access. The I/O manager

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > FYI, here are the access rights applicable to files Thanks, I checked that mapping in headers when I was writing _Py_wopen_noraise() as well. But I've found a catch via ProcessHacker: CreateFile() with GENERIC_WRITE (or FILE_GENERIC_WRITE) additionally

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Eryk Sun added the comment: FYI, here are the access rights applicable to files, including their membership in generic (R)ead, (W)rite, and e(X)execute access: 0x0100_ --- ACCESS_SYSTEM_SECURITY 0x0010_ RWX SYNCHRONIZE 0x0008_ --- WRITE_OWNER 0x0004_ ---

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > I don't know what you mean by default access rights. I meant the access rights of the handle created by _wopen(). In my PR I basically assume that _wopen() uses GENERIC_READ/GENERIC_WRITE access rights, but _wopen() doesn't have a contractual obligation

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Eryk Sun added the comment: > can a new handle have non-default access rights? Or can the > default change at this point of Windows history? I don't know what you mean by default access rights. C open() requests generic access rights, which map to the standard and file-specific rights in

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: > It's possible to query the granted access of a kernel handle via > NtQueryObject: ObjectBasicInformation Ah, thanks for the info. But it wouldn't help for option (1) that I had in mind because open() and os.open() currently set only msvcrt-level

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Eryk Sun 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

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Alexey Izbyshev added the comment: Could anybody provide their thoughts on this RFE? Thanks. -- ___ Python tracker ___ ___

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

Change by Alexey Izbyshev : -- keywords: +patch pull_requests: +22575 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23712 ___ Python tracker ___

[issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows

New submission from Alexey 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