Alexey Izbyshev <izbys...@ispras.ru> 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 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42606> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
