From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [Qemu-devel] [PATCH] rev3: support colon in filenames Date: Thu, 02 Jul 2009 15:18:23 +0200 Message-ID: <4A4CB39F.5070506@redhat.com> References: <1245862739.6278.7.camel@localhost> <1245866233.6278.17.camel@localhost> <4A434009.5010009@redhat.com> <1245998284.6278.99.camel@localhost> <4A447C8D.5000104@kevin-wolf.de> <1246063310.6278.115.camel@localhost> <1246511321.6429.31.camel@localhost> <4A4C754D.10109@redhat.com> <4A4CAD86.9020607@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: linuxram@us.ibm.com, qemu-devel@nongnu.org, kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44804 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751890AbZGBNTa (ORCPT ); Thu, 2 Jul 2009 09:19:30 -0400 In-Reply-To: <4A4CAD86.9020607@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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: Is there any way to usb_add a fat:rw:/path filesystem? usb_add disk::fat:rw:/tmp/foo Kevin