qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH] Modify qemu-img can not create local filename contain ":"
Date: Mon, 03 Mar 2014 19:06:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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) –
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.
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. 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]