This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author izbyshev
Recipients eryksun, izbyshev, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2021-01-21.17:46:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1611251200.58.0.3792964554.issue42606@roundup.psfhosted.org>
In-reply-to
Content
> 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 O_APPEND.

It probably could be used in my current PR instead of just assuming the default access rights for file handles, but I'm not sure whether it makes sense: can a new handle have non-default access rights? Or can the default change at this point of Windows history?

> 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.

Would it be a long shot to ask MS to add the needed functionality to MSVCRT instead? Or at least to declare the bug with _umask_s() that I described a feature. Maybe Steve Dower could help.

> 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.

I didn't know that, thanks. Indeed, a simple open(path, 'w') fails on a hidden file with "Permission denied".

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

Yes, I'd be glad to move support for more obscure MSVCRT flags to msvcrt.open() -- the less MSVCRT details we leak in os.open(), the more freedom we have to implement it via proper Win32 APIs.

===

Anyway, even if the blockers for implementing open()/os.open() via CreateFile() are solved, my current PR doesn't seem to conflict with such an implementation (it could just be replaced in the future).

Currently, the only way to achieve atomic append in Python on Windows that I know is to use a custom opener that would call CreateFile() with the right arguments via ctypes/pywin32/etc.
History
Date User Action Args
2021-01-21 17:46:40izbyshevsetrecipients: + izbyshev, paul.moore, vstinner, tim.golden, zach.ware, eryksun, steve.dower
2021-01-21 17:46:40izbyshevsetmessageid: <1611251200.58.0.3792964554.issue42606@roundup.psfhosted.org>
2021-01-21 17:46:40izbyshevlinkissue42606 messages
2021-01-21 17:46:40izbyshevcreate