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 '/'. > > 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
