Awesome detail. Thanks eryk.
On Tue, 20 Sep 2016, 6:13 PM eryk sun <eryk...@gmail.com> wrote:
> On Mon, Sep 19, 2016 at 10:21 PM, Christopher Nilsson <ch...@slort.org>
> > 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 mailing list