From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwVyk-0004fd-KN for qemu-devel@nongnu.org; Wed, 11 Nov 2015 09:02:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwVye-0001Ow-IV for qemu-devel@nongnu.org; Wed, 11 Nov 2015 09:02:26 -0500 Received: from e19.ny.us.ibm.com ([129.33.205.209]:43906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwVye-0001Oo-EO for qemu-devel@nongnu.org; Wed, 11 Nov 2015 09:02:20 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 11 Nov 2015 09:02:18 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: <56423076.5020408@redhat.com> References: <1447105745-32358-1-git-send-email-kallan@suse.com> <20151110154059.25378.38107@loki> <56423076.5020408@redhat.com> Message-ID: <20151111140208.31702.72506@loki> Date: Wed, 11 Nov 2015 08:02:08 -0600 Subject: Re: [Qemu-devel] [PATCH] qga: fix append file open modes for win32 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Kirk Allan , qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org 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=3Dv= s.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 > =3D FILE_READ_DATA > + FILE_READ_ATTRIBUTES > + FILE_READ_EA > + SYNCHRONIZE > + STANDARD_RIGHTS_READ (which is READ_CONTROL) > = > GENERIC_WRITE for files > =3D 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 SYNCHRONIZ= E. > = > 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=3Dvs.= 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 >=20