Re: [Qemu-devel] [PATCH] rev3: support colon in filenames

[Kevin Wolf]

Anthony Liguori schrieb:
> Kevin Wolf wrote:
>> Ram Pai schrieb:
>>   
>>> Problem: It is impossible to feed filenames with the character colon because
>>> qemu interprets such names as a protocol. For example filename scsi:0, is
>>> interpreted as a protocol by name "scsi".
>>>
>>> This patch allows user to escape colon characters. For example the above
>>> filename can now be expressed either as 'scsi\:0' or as file:scsi:0
>>>
>>> anything following the "file:" tag is interpreted verbatim. However if 
>>> "file:"
>>> tag is omitted then any colon characters in the string must be escaped using
>>> backslash.
>>>     
>> Anthony has already committed version 2 of the patch, so this one
>> doesn't apply any more.
>>
>> By the way, I'm still not convinced that this use of backslashes gives
>> us anything but yet another special character that worked just fine
>> before. I guess this is going to be annoying for Windows users.
>>   
> 
> It ends up working out for Windows users because colons are invalid in 
> Windows file names.

It could work as long as combinations of backslash + random character
are interpreted this way instead of having a special meaning for
everything after a backslash.

> What's the solution to this problem is we don't escape?

The majority of cases is covered by the file: protocol. I haven't
thought of things like vvfat before though, so the combination of vvfat
and a directory named :floppy: actually wouldn't work.

Can we at least allow \, instead of ,, in parameter parsing, so that the
backslash has the practical benefit of being a single universal escape
character?

>>> fat:c:\path\to\dir\:floppy\:  is a fat file by name \path\to\dir:floppy:
>>> NOTE:The above example cannot be expressed using the "file:" protocol.
>>>     
>> And it doesn't need to. It's already expressed using the "fat:"
>> protocol, so we won't accidentally mistake c for the protocol name.
>>
>> You might have a point with a directory named :floppy: or so.
> 
> For 0.12, maybe we should take a hard look at refactoring -drive and 
> completely splitting this stuff.  I think we ought to come up with a 
> syntax where we can pass file names as independent arguments so that no 
> special escaping is required.

What makes such a change more difficult is that it's not only -drive.
The string is parsed in multiple locations. -drive only introduces the
problem of commas, escaped by double comma. The next one is the generic
block code which uses a colon to determine the protocol. And then vvfat
comes and uses even more colons to find its arguments. Each of them are
completely separate issues.

Btw, I answered a related question in IRC today - I'll leave it uncommented:

<DeadPanda> Is there any way to usb_add a fat:rw:/path filesystem?
<kwolf> usb_add disk::fat:rw:/tmp/foo

Kevin