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 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.