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 09:39:21 -0600 [thread overview]
Message-ID: <20151111153921.31702.6490@loki> (raw)
In-Reply-To: <56435595.7010704@redhat.com>
Quoting Paolo Bonzini (2015-11-11 08:49:57)
>
>
> On 11/11/2015 15:02, Michael Roth wrote:
> >> 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
>
> Yes, I had missed the FILE_GENERIC_* definitions. I found them now in
> mingw as well, and they are exactly what you would expect (an | of the
> various flags).
>
> > 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.
>
> For a+ I would use any of
>
> (FILE_GENERIC_READ | FILE_GENERIC_WRITE) & ~FILE_WRITE_DATA
> GENERIC_READ | (FILE_GENERIC_WRITE & ~FILE_WRITE_DATA)
>
> Perhaps you can define this:
>
> #define FILE_GENERIC_APPEND (FILE_GENERIC_WRITE & ~FILE_WRITE_DATA)
>
> and then use
>
> a: FILE_GENERIC_APPEND
> a+: GENERIC_READ|FILE_GENERIC_APPEND
>
> or
>
> a: FILE_GENERIC_APPEND
> a+: FILE_GENERIC_READ|FILE_GENERIC_APPEND
Yah, both are more proper actually (I was relying on FILE_GENERIC_READ
already containing the other flags from FILE_GENERIC_WRITE, but that's
more likely to break in the future).
I think I prefer the former since it avoids confusion on GENERIC_READ vs.
FILE_GENERIC_READ differences.
Kirk, I'm planning on squashing this into your v2 series, so no need to
resubmit.
Thanks!
>
> ?
>
> Paolo
>
next prev parent reply other threads:[~2015-11-11 15:41 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
2015-11-11 14:49 ` Paolo Bonzini
2015-11-11 15:39 ` Michael Roth [this message]
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=20151111153921.31702.6490@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 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).