From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMMCQ-0007Tz-5j for qemu-devel@nongnu.org; Thu, 02 Jul 2009 09:19:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMMCL-0007Ry-Ez for qemu-devel@nongnu.org; Thu, 02 Jul 2009 09:19:37 -0400 Received: from [199.232.76.173] (port=50572 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMMCK-0007Rq-VC for qemu-devel@nongnu.org; Thu, 02 Jul 2009 09:19:33 -0400 Received: from mx2.redhat.com ([66.187.237.31]:48610) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MMMCK-0006WN-BO for qemu-devel@nongnu.org; Thu, 02 Jul 2009 09:19:32 -0400 Message-ID: <4A4CB39F.5070506@redhat.com> Date: Thu, 02 Jul 2009 15:18:23 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] rev3: support colon in filenames 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> In-Reply-To: <4A4CAD86.9020607@us.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: linuxram@us.ibm.com, qemu-devel@nongnu.org, kvm-devel 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