From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKXCt-0003e5-Dk for qemu-devel@nongnu.org; Mon, 03 Mar 2014 13:03:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKXCo-0002N3-Ex for qemu-devel@nongnu.org; Mon, 03 Mar 2014 13:03:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKXCo-0002Mq-6v for qemu-devel@nongnu.org; Mon, 03 Mar 2014 13:03:10 -0500 Message-ID: <5314C3D9.2080305@redhat.com> Date: Mon, 03 Mar 2014 11:03:05 -0700 From: Eric Blake MIME-Version: 1.0 References: <1393855339-13878-1-git-send-email-junmuzi@gmail.com> <5314C01B.2020301@redhat.com> In-Reply-To: <5314C01B.2020301@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pWkLVmDn8xC7sXgMhuWXD0EnRB1FDlrUQ" Subject: Re: [Qemu-devel] [PATCH] Modify qemu-img can not create local filename contain ":" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , Jun Li , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pWkLVmDn8xC7sXgMhuWXD0EnRB1FDlrUQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/03/2014 10:47 AM, Max Reitz wrote: >=20 > Currently, a protocol prefix is only defined to end with a colon, not > with ":/" or "://". There are already protocol block drivers which do > not require a slash after the colon such as blkdebug or blkverify and I= > deem it rather impossible to redefine their filename format now (in > order to make them use ":/"). It should ALWAYS be possible to open a file via absolute path, or via './file:with:colon'. That is, our check for a protocol should be any prefix that contains a ':' prior to a '/'. >=20 > Thus, I do not think it will be this easy. I am in fact not even sure > whether it is possible at all (automagically doing the right thing) =E2= =80=93 > currently, a colon simpy is the separator between protocol and filename= =2E > Just using the "file" protocol per default for the whole filename if > there is no protocol with a name equal to the pre-colon part is probabl= y > not what we want, since the user may actually be referring to some > protocol that the qemu version he/she is using does not support (yet), > in which case creating a file with a name including the pre-colon part > (the protocol name) is most probably not the right thing to do. If the user wants a file name that contains a colon, use either an absolute path name, or prefix the relative name with './'. Either way should cause a '/' to occur before the first ':', and since a protocol consists only of a prefix prior to ':' without '/', it then becomes obvious that a file name is intended. >=20 > Henceforth, in my opinion, we either have to ask the user in that case > or we introduce some new option which disables protocol prefixes. I > think the easiest way to do the latter is to introduce a > bdrv_parse_filename() function for the "file" protocol drivers which > remove a "file:" prefix if given. Then, the user could just specify > "file:foo:bar.img" to reference a file named "foo:bar.img". Yes, this would also make sense, if you can't live with './foo:bar.img'. >=20 > Currently, the behavior is that such a prefix will be interpreted > correctly (the "file" protocol is selected) but it is not removed. Thus= , > "file:foo:bar.img" will actually reference a file named > "file:foo:bar.img". One could argue that removing the prefix therefore > breaks current behavior, but I sincerely hope nobody has relied on that= > behavior so far. I think the fact that the file: prefix is NOT removed before hitting the filesystem is a bug worth fixing - it should be fairly obvious that the relative name in the filesystem should not include the 'file:' prefix, but that 'file:' was the protocol that forced interpretation of the rest of the string as a local filename. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --pWkLVmDn8xC7sXgMhuWXD0EnRB1FDlrUQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTFMPZAAoJEKeha0olJ0NqX5gH/30ok2wX/t12oiQ5lyUwU8gd h1gV8IGtAElBAgphq2+BKutrPDAm1GnkqT02E+AQ9tJQaRPEHf6OuUErg86acfIZ FTR/2JEuhhWp2pTK5Zv/JCyVAw/GT3fqNxLKmLaKgOeB+M7miiDvJAz6p/37wlBh 4rQxG3KlXu9chlFGsQyxYDJ0AaC9gpwgiRhagPnEQ/kDowfTAbYJ6qVNzHJzl6aY URB9XVG5KvhiSMdkvYwRoIlxuUlO21HRf6FaqWyGQn2+E3eWk9Ur1WrMEgtYDvQB jC83MgS3K8/SLtRG4urGMVNG75iaqzcUsjrQo3wdlj8UqW+e2Hw152qY4KeHhao= =RGgA -----END PGP SIGNATURE----- --pWkLVmDn8xC7sXgMhuWXD0EnRB1FDlrUQ--