From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>,
Kirk Allan <kallan@suse.com>,
qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qga: fix append file open modes for win32
Date: Tue, 10 Nov 2015 18:59:18 +0100 [thread overview]
Message-ID: <56423076.5020408@redhat.com> (raw)
In-Reply-To: <20151110154059.25378.38107@loki>
On 10/11/2015 16:40, Michael Roth wrote:
>
> I hit an issue testing this though, this does fix the append
> case, but a+, ab+, a+b all imply append+read, while
> FILE_APPEND_DATA only grants append access.
>
> FILE_APPEND_DATA|GENERIC_READ seems to work, but I'm not
> finding much official documentation on what's valid with
> FILE_APPEND_DATA. Do you have a reference that might
> confirm this is valid usage? The only reference to
> FILE_APPEND_DATA I saw was a single comment in:
I found a few references to FILE_APPEND_DATA, but not to combining it
with GENERIC_READ.
https://msdn.microsoft.com/en-us/library/windows/desktop/gg258116%28v=vs.85%29.aspx
(File Access Rights Constants) under FILE_APPEND_DATA says "For a file
object, the right to append data to the file. (For local files, write
operations will not overwrite existing data if this flag is specified
without FILE_WRITE_DATA.)".
https://msdn.microsoft.com/en-us/library/ff548289.aspx also says:
* If only the FILE_APPEND_DATA and SYNCHRONIZE flags are set, the caller
can write only to the end of the file, and any offset information about
writes to the file is ignored. However, the file will automatically be
extended as necessary for this type of write operation.
* Setting the FILE_WRITE_DATA flag for a file also allows writes beyond
the end of the file to occur. The file is automatically extended for
this type of write, as well.
Regarding the combination of reading and appending, GENERIC_READ and
GENERIC_WRITE are sort of "macro" access rights, which expand to
different attributes depending on what you're opening. For files,
FILE_WRITE_DATA and FILE_READ_DATA are part of GENERIC_READ and
GENERIC_WRITE:
GENERIC_READ for files
= FILE_READ_DATA
+ FILE_READ_ATTRIBUTES
+ FILE_READ_EA
+ SYNCHRONIZE
+ STANDARD_RIGHTS_READ (which is READ_CONTROL)
GENERIC_WRITE for files
= FILE_APPEND_DATA
+ FILE_WRITE_DATA
+ FILE_WRITE_ATTRIBUTES
+ FILE_WRITE_EA
+ SYNCHRONIZE
+ STANDARD_RIGHTS_WRITE (which is READ_CONTROL too!)
Of these of course qemu-ga only needs FILE_*_DATA and possibly SYNCHRONIZE.
The above description doesn't say what happens if you specify
FILE_READ_DATA and FILE_APPEND_DATA together, but I guess you can expect
it to just work.
Paolo
next prev parent reply other threads:[~2015-11-10 17:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-09 21:49 [Qemu-devel] [PATCH] qga: fix append file open modes for win32 Kirk Allan
2015-11-10 15:40 ` Michael Roth
2015-11-10 17:59 ` Paolo Bonzini [this message]
2015-11-10 20:45 ` Kirk Allan
2015-11-11 14:02 ` Michael Roth
2015-11-11 14:49 ` Paolo Bonzini
2015-11-11 15:39 ` Michael Roth
2015-11-11 15:42 ` Kirk Allan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56423076.5020408@redhat.com \
--to=pbonzini@redhat.com \
--cc=kallan@suse.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).