From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.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: Wed, 11 Nov 2015 08:02:08 -0600 [thread overview]
Message-ID: <20151111140208.31702.72506@loki> (raw)
In-Reply-To: <56423076.5020408@redhat.com>
Quoting Paolo Bonzini (2015-11-10 11:59:18)
>
>
> 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.
Thanks, this is very helpful. This seems to coincide with
FILE_GENERIC_WRITE / FILE_GENERIC_READ if you want to access the
bitmasks directly (though it looks like you can still add flags
to GENERIC_WRITE / GENERIC_READ):
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364399(v=vs.85).aspx
Looks like the crux of it is that FILE_WRITE_DATA causes us not to ignore
the start offset (0) for writes, so we end up writing data at the
beginning of the file instead of the end.
So I think the following
should work:
a: FILE_GENERIC_WRITE & ~FILE_WRITE_DATA
a+: FILE_GENERIC_READ | FILE_APPEND_DATA
FILE_APPEND_DATA by itself might work for a:, but for consistency I
think I'd prefer sticking with the generic set and masking out
FILE_WRITE_DATA.
>
> Paolo
>
next prev parent reply other threads:[~2015-11-11 14:02 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
2015-11-10 20:45 ` Kirk Allan
2015-11-11 14:02 ` Michael Roth [this message]
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=20151111140208.31702.72506@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=kallan@suse.com \
--cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.