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.22:56:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1611269780.08.0.459940292885.issue42606@roundup.psfhosted.org>
In-reply-to
Content
> 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.
History
Date User Action Args
2021-01-21 22:56:20izbyshevsetrecipients: + izbyshev, paul.moore, vstinner, tim.golden, zach.ware, eryksun, steve.dower
2021-01-21 22:56:20izbyshevsetmessageid: <1611269780.08.0.459940292885.issue42606@roundup.psfhosted.org>
2021-01-21 22:56:20izbyshevlinkissue42606 messages
2021-01-21 22:56:20izbyshevcreate