From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LgHBV-0003w5-Fd for qemu-devel@nongnu.org; Sun, 08 Mar 2009 07:28:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LgHBO-0003u1-1O for qemu-devel@nongnu.org; Sun, 08 Mar 2009 07:28:42 -0400 Received: from [199.232.76.173] (port=48236 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LgHBM-0003tn-NT for qemu-devel@nongnu.org; Sun, 08 Mar 2009 07:28:36 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58311) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LgHBM-0007Dj-3t for qemu-devel@nongnu.org; Sun, 08 Mar 2009 07:28:36 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n28BSWT6011750 for ; Sun, 8 Mar 2009 07:28:32 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n28BSXXo032687 for ; Sun, 8 Mar 2009 07:28:33 -0400 Received: from [10.35.1.187] (dhcp-1-187.tlv.redhat.com [10.35.1.187]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n28BSVbM010556 for ; Sun, 8 Mar 2009 07:28:32 -0400 Message-ID: <49B3ABDF.2080803@redhat.com> Date: Sun, 08 Mar 2009 13:28:31 +0200 From: Uri Lublin MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH][RFC] Handling ':' on filenames References: <20090306212830.GL5077@blackpad> In-Reply-To: <20090306212830.GL5077@blackpad> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Eduardo Habkost wrote: > This patch fixes this issue: > > $ qemu-img create -f qcow2 /tmp/a:b 1G > $ qemu-system-x86_64 -hda qcow2:/tmp/a:b > qemu: could not open disk image /tmp/a:b > $ This patch looks good to me with the following comments: 1. I think the example above is wrong. a. There is no protocol "qcow2" b. We do not want to use "qcow2:/tmp/a:b" as filenames (been there). We want to use -drive file=/tmp/a:b,format=qcow2 (and similar "qemu-img info -f "). c. But, without this patch, even when using appropriate -drive, we'd still get the same result (could not open disk image). Qemu considers "/tmp/a" to be a protocol, which does not exist, so Qemu fails to open the image. With this patch, Qemu opens the file successfully. > > Based on a suggestion by Daniel Berrange. > > However, this is still just a workaround. The semantics of filenames > containing colon characters (and how this can be escaped, avoided, > or worked around) are not very clear. > > Going further, what if we stop using "protocol:filename" strings > internally, except where the user interface or external data really > requires this format? 2. Do you mean something like adding a '-drive protocol=xxx' option ? > > Signed-off-by: Eduardo Habkost > --- > block.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/block.c b/block.c > index 7c744c7..04488d6 100644 > --- a/block.c > +++ b/block.c > @@ -236,6 +236,14 @@ static BlockDriver *find_protocol(const char *filename) > is_windows_drive_prefix(filename)) > return &bdrv_raw; > #endif > + > + /* Protocol name will never start with a slash. > + * This allows the user to specify absolute filenames > + * containing a ":" character. > + */ > + if (*filename == '/') > + return &bdrv_raw; 3. The patch limits protocols names to not start with '/' (full paths). I think we should apply the same logic to relative paths, so protocol names would not start with '.' as well (no protocol starts with '.' today): + if ((*filename == '/') || (*filename == '.')) + return &bdrv_raw; 4. Note that this patch does not limit image formats to raw, it just says "use no protocols for full/relative paths". > + > p = strchr(filename, ':'); > if (!p) > return &bdrv_raw; Regards, Uri.