On Mon, Sep 19, 2016 at 10:21 PM, Christopher Nilsson <ch...@slort.org> wrote:
>
> That doesn't seem like a bug to me. GENERIC_WRITE represents several
> permissions mashed together, including FILE_WRITE and read control.
>
> Perhaps try with just FILE_WRITE on its own?
For a file or directory, GENERIC_WRITE (0x80000000) gets mapped to
FILE_GENERIC_WRITE, which includes the following standard rights
(upper 16 bits):
SYNCHRONIZE = 0x00100000
READ_CONTROL = 0x00020000
and File-object specific rights (lower 16 bits):
FILE_WRITE_ATTRIBUTES = 0x00000100
FILE_WRITE_EA = 0x00000010
FILE_APPEND_DATA = 0x00000004
FILE_WRITE_DATA = 0x00000002
The relevant access right that's being denied in this case is SYNCHRONIZE.
For example, SetCurrentDirectory uses a synchronous directory handle,
i.e. it calls NtOpenfile with desired access SYNCHRONIZE |
FILE_TRAVERSE and open option FILE_SYNCHRONOUS_IO_NONALERT. Similarly,
for listing a directory, FindFirstFile uses a synchronous handle with
SYNCHRONIZE | FILE_LIST_DIRECTORY access.
The open option FILE_SYNCHRONOUS_IO_NONALERT is defined as follows:
All operations on the file are performed synchronously.
Waits in the system that synchronize I/O queuing and
completion are not subject to alerts. This flag also
causes the I/O system to maintain the file-position
context. If this flag is set, the SYNCHRONIZE flag must
be set in the DesiredAccess parameter.
For example, when FindFirstFile calls NtQueryDirectoryFile
(FileBothDirectoryInformation) to list the directory, the system call
sees the handle is opened for synchronous access, so it waits to
acquire the File object's Lock before calling the filesystem driver
(e.g. NTFS). Then it waits again to complete the request.
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
