Alexey Izbyshev <izbys...@ispras.ru> 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 to do exactly that AFAIU. For example, if it got some extra access rights, then my code would "drop" them while switching FILE_WRITE_DATA off. > For example, if FILE_WRITE_DATA isn't granted, then open() can't open for > appending. A direct CreateFileW() call can remove FILE_WRITE_DATA from the > desired access. Indeed, I haven't thought about it. Are you aware of a common scenario when a regular file allows appending but not writing? But, at least, this is not a regression: currently open()/os.open() can't open such files for appending too. > An opener could also work like your PR via os.open(), msvcrt.get_osfhandle(), > _winapi.GetFileType(), _winapi.DuplicateHandle(), os.close(), and > msvcrt.open_osfhandle(). True, but it still falls into "etc" category of "ctypes/pywin32/etc" :) Certainly doable, but it seems better to have consistent O_APPEND behavior across platforms out-of-the-box. ---------- _______________________________________ 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
