From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKXGV-0006G7-9x for qemu-devel@nongnu.org; Mon, 03 Mar 2014 13:07:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKXGL-0003f6-DJ for qemu-devel@nongnu.org; Mon, 03 Mar 2014 13:06:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKXGL-0003eo-54 for qemu-devel@nongnu.org; Mon, 03 Mar 2014 13:06:49 -0500 Message-ID: <5314C4B4.1060905@redhat.com> Date: Mon, 03 Mar 2014 19:06:44 +0100 From: Max Reitz MIME-Version: 1.0 References: <1393855339-13878-1-git-send-email-junmuzi@gmail.com> <5314C01B.2020301@redhat.com> <5314C3D9.2080305@redhat.com> In-Reply-To: <5314C3D9.2080305@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Eric Blake , Jun Li , qemu-devel@nongnu.org On 03.03.2014 19:03, Eric Blake wrote: > On 03/03/2014 10:47 AM, Max Reitz wrote: > >> 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 '/'. Oh, yes, you are right, I forgot about that. Max > >> 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 filenam= e. >> 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 probab= ly >> 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. > >> 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'. > >> Currently, the behavior is that such a prefix will be interpreted >> correctly (the "file" protocol is selected) but it is not removed. Thu= s, >> "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 tha= t >> behavior so far. > I think the fact that the file: prefix is NOT removed before hitting th= e > 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 res= t > of the string as a local filename. >