From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw9fJ-0004jX-G3 for qemu-devel@nongnu.org; Wed, 03 Dec 2014 08:08:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xw9fD-0003Q8-CU for qemu-devel@nongnu.org; Wed, 03 Dec 2014 08:08:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw9fD-0003Q2-3B for qemu-devel@nongnu.org; Wed, 03 Dec 2014 08:08:15 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB3D8DWM009571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 3 Dec 2014 08:08:14 -0500 Message-ID: <547F0B39.5050706@redhat.com> Date: Wed, 03 Dec 2014 14:08:09 +0100 From: Max Reitz MIME-Version: 1.0 References: <1417598601-18537-1-git-send-email-mreitz@redhat.com> <1417598601-18537-2-git-send-email-mreitz@redhat.com> <20141203124436.GD4404@noname.str.redhat.com> In-Reply-To: <20141203124436.GD4404@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] vmdk: Fix error for JSON descriptor file names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi On 2014-12-03 at 13:44, Kevin Wolf wrote: > Am 03.12.2014 um 10:23 hat Max Reitz geschrieben: >> If vmdk blindly tries to use path_combine() using bs->file->filename as >> the base file name, this will result in a bad error message for JSON >> file names when calling bdrv_open(). It is better to only try >> bs->file->exact_filename; if that is empty, bs->file->filename will be >> useless for path_combine() and an error should be emitted (containing >> bs->file->filename because bs->file->exact_filename is empty). >> >> Note that s->create_type does not need to be freed on error because it >> will be freed by the caller (which ultimately is vmdk_open()). >> >> Signed-off-by: Max Reitz >> --- >> block/vmdk.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/block/vmdk.c b/block/vmdk.c >> index 2cbfd3e..fe549c2 100644 >> --- a/block/vmdk.c >> +++ b/block/vmdk.c >> @@ -894,7 +894,14 @@ static int vmdk_open_desc_file(BlockDriverState *bs, int flags, char *buf, >> } >> s->create_type = g_strdup(ct); >> s->desc_offset = 0; >> - ret = vmdk_parse_extents(buf, bs, bs->file->filename, errp); >> + >> + if (!bs->file->exact_filename[0]) { >> + error_setg(errp, "Cannot use extents with VMDK descriptor file '%s'", >> + bs->file->filename); >> + ret = -EINVAL; >> + goto exit; >> + } > Isn't this overly restrictive? If the extent paths are all absolute, > there is no reason not to open them. Or does the VMDK spec say that they > are always relative? Yes, you're right. Will respin. Max >> + ret = vmdk_parse_extents(buf, bs, bs->file->exact_filename, errp); >> exit: >> return ret; >> } > Kevin