Message385456
> 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. |
|
Date |
User |
Action |
Args |
2021-01-21 22:56:20 | izbyshev | set | recipients:
+ izbyshev, paul.moore, vstinner, tim.golden, zach.ware, eryksun, steve.dower |
2021-01-21 22:56:20 | izbyshev | set | messageid: <1611269780.08.0.459940292885.issue42606@roundup.psfhosted.org> |
2021-01-21 22:56:20 | izbyshev | link | issue42606 messages |
2021-01-21 22:56:20 | izbyshev | create | |
|