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 |
for listing a directory, FindFirstFile uses a synchronous handle with

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

Reply via email to