From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxPBN-00055Z-An for qemu-devel@nongnu.org; Thu, 01 Apr 2010 14:31:57 -0400 Received: from [140.186.70.92] (port=49329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxPBK-00054l-AY for qemu-devel@nongnu.org; Thu, 01 Apr 2010 14:31:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxPBB-0000NQ-1q for qemu-devel@nongnu.org; Thu, 01 Apr 2010 14:31:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19414) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxPBA-0000NK-PZ for qemu-devel@nongnu.org; Thu, 01 Apr 2010 14:31:44 -0400 Date: Thu, 1 Apr 2010 15:31:36 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH] Add qerror message if the 'change' target filename can't be opened Message-ID: <20100401153136.60687c44@redhat.com> In-Reply-To: <20100401182344.GV24351@us.ibm.com> References: <20100325143258.GS27260@us.ibm.com> <20100401151551.443ba961@redhat.com> <20100401182344.GV24351@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Harper Cc: qemu-devel@nongnu.org On Thu, 1 Apr 2010 13:23:44 -0500 Ryan Harper wrote: > * Luiz Capitulino [2010-04-01 13:17]: > > 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. > > That's true, but that happens whether or not we indicate the change > failed. I think fixing that is a good idea, but it shouldn't part of > this patch (just indicating the failure). Sure, this patch is good by itself.