Re: [Qemu-devel] [PATCH] Modify qemu-img can not create local filename contain ":"

[Max Reitz <mreitz@redhat.com>]

On 03.03.2014 15:02, Jun Li wrote:
> Such as how to visit glusterfs:
> file=gluster://1.2.3.4/testvol/a.img
> file=gluster+tcp://1.2.3.4/testvol/a.img
> file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
> file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
> file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
> file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
> file=gluster+rdma://1.2.3.4:24007/testvol/a.img
> ----
> So if only the path contain "://", the path maybe contain a protocol. So use
> strstr() to replace func strcspn().
>
> Signed-off-by: Jun Li <junmuzi@gmail.com>
> ---
>   block.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>

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 ":/").

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) – 
currently, a colon simpy is the separator between protocol and filename. 
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 probably 
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.

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".

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.


Max