qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Iustin Pop <iusty@k1024.org>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>
Subject: [Qemu-devel] [PATCH] block: handle filenames with colons better
Date: Thu, 16 Aug 2012 16:58:36 +0200	[thread overview]
Message-ID: <20120816145836.GA6793@hq.k1024.org> (raw)

Commit 947995c (block: protect path_has_protocol from filenames with
colons) introduced a way to handle filenames with colons based on
whether the path contains a slash or not. IMHO this is not optimal,
since we shouldn't rely on the contents of the path but rather on
whether the given path exists as a file or not.

As such, this patch tries to handle both files with and without
slashes by falling back to opening them as files if no drivers
supporting the protocol has been identified.

Signed-off-by: Iustin Pop <iusty@k1024.org>
---
 I've tested this with both slash-containing and slash-free names and it works
 as expected. I believe falling back to file is safe, as the "file"
 block driver will just fail and return NULL if the path doesn't exist.

 Side note: this is the third way that a file can be opened, and as such
 the code flow is quite unclear; first, paths pointing to block or char
 devices are opened in any case, even if they have colons, since the
 call to find_hdev_driver will probe for the and the raw drivers will
 identify them; second, slash-containing paths will be opened via the
 first call to bdrv_find_format("file") since path_has_protocol will
 return false; and finally, slash-free paths will be opened in this
 second call to said function. I don't know if all this could be cleaned
 and organised better.

 block.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/block.c b/block.c
index 470bdcc..367879f 100644
--- a/block.c
+++ b/block.c
@@ -499,7 +499,12 @@ BlockDriver *bdrv_find_protocol(const char *filename)
             return drv1;
         }
     }
-    return NULL;
+    /*
+     * No bdrv_driver identified the protocol we extracted from the
+     * path; maybe this is not actually a protocol, but just a file
+     * containing a colon? Fallback to bdrv_find_format.
+     */
+    return bdrv_find_format("file");
 }
 
 static int find_image_format(const char *filename, BlockDriver **pdrv)
-- 
1.7.10

             reply	other threads:[~2012-08-16 14:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 14:58 Iustin Pop [this message]
2012-08-16 19:24 ` [Qemu-devel] [PATCH] block: handle filenames with colons better Michael Tokarev
2012-08-17  7:15   ` Iustin Pop
2012-08-17  7:56     ` Kevin Wolf
2012-08-17 10:05       ` Iustin Pop
2012-08-17 10:15         ` Kevin Wolf
2012-08-17 22:39           ` Iustin Pop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120816145836.GA6793@hq.k1024.org \
    --to=iusty@k1024.org \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).