From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxPrH-0005Wa-Dg for qemu-devel@nongnu.org; Thu, 01 Apr 2010 15:15:15 -0400 Received: from [140.186.70.92] (port=46524 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxPrF-0005Sz-A2 for qemu-devel@nongnu.org; Thu, 01 Apr 2010 15:15:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxPrD-0005l5-LH for qemu-devel@nongnu.org; Thu, 01 Apr 2010 15:15:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30531) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxPrD-0005ki-DV for qemu-devel@nongnu.org; Thu, 01 Apr 2010 15:15:11 -0400 Message-ID: <4BB4F096.10302@redhat.com> Date: Thu, 01 Apr 2010 21:14:30 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add qerror message if the 'change' target filename can't be opened References: <20100325143258.GS27260@us.ibm.com> <20100401151551.443ba961@redhat.com> <20100401152233.71e778ed@redhat.com> In-Reply-To: <20100401152233.71e778ed@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Ryan Harper , qemu-devel@nongnu.org, Juan Quintela Am 01.04.2010 20:22, schrieb Luiz Capitulino: > On Thu, 1 Apr 2010 15:15:51 -0300 > Luiz Capitulino wrote: > >> On Thu, 25 Mar 2010 09:32:58 -0500 >> Ryan Harper wrote: >> >>> Currently when using the change command to switch the file in the cd drive >>> the command doesn't complain if the file doesn't exit or can't be opened >>> and the drive keeps the existing image. This patch adds a qerror_report >>> call to print a message out indicating the failure. This error message >>> can be used to catch failures. >> >> Looks good to me, but it doesn't keep the existing image, it will silently >> eject it instead. > > And, thinking more about it this seems the wrong behavior to me, if it > fails to open the file, it should not touch the current one. > > Am I right, Kevin? Well, it's a monitor command. I guess its meaning has never been clearly defined, so I tend to say there is no right or wrong. From a user perspective, intuitively I would expect that it succeeds completely or maintains the old state, so yes. However, I don't think it's fixable that easy. You obviously need to close the image before you can open it. And reopening the image in case of failure - well, we just had this discussion and I'm sure Juan wants to comment on it... It's a case that we should consider if/when we reorganize bdrv_open. The "bdrv_close, but without closing the fd" thing doesn't work out here because we need to reuse the same bs. Or maybe open a different bs first and then copy things over. Could actually work this way. Kevin