From patchwork Thu Aug 16 14:58:36 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Iustin Pop X-Patchwork-Id: 178056 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 462572C009D for ; Fri, 17 Aug 2012 03:43:12 +1000 (EST) Received: from localhost ([::1]:59801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T246A-0005BO-Bj for incoming@patchwork.ozlabs.org; Thu, 16 Aug 2012 13:43:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T21Xe-0000Fh-Sw for qemu-devel@nongnu.org; Thu, 16 Aug 2012 10:59:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T21Xd-0001SW-NV for qemu-devel@nongnu.org; Thu, 16 Aug 2012 10:59:22 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:37746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T21Xd-0001SF-Hi for qemu-devel@nongnu.org; Thu, 16 Aug 2012 10:59:21 -0400 Received: by wibhm2 with SMTP id hm2so583006wib.10 for ; Thu, 16 Aug 2012 07:59:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:x-linux:x-header:user-agent:x-gm-message-state; bh=sivPfBhPl4NcGLuHNAkfdiJjJqIc3p/Zmqh+dt/5phc=; b=IRbkWnc23iWrEe31qTEtKIm8hBR2/eY3Kt1uOAT4HLL0CFnBS6PmDCY/qYj6BypjIG Pf/yaVYQjhKJNkrTMSl6Wx++atcvZHFbuJh1b1ibQTZn3spIyrN57J80DQSz2vaIE+G4 dTnJ3M6/YKga5LnipVl9EQxTt4INyE2i+CKPYj+a0WqfW69O7wlpHvd53HSwLY+/1y1M HgHD5R8W95+WX0wuS/f1RuX8Nr5kOrgvPFfN5lttnnSp08dvGbqdJuPTm7LEcmFegEiU +COaWqq59p+8byrNC260MRjQ6UAuTF5fs7DK9Nru0XZ/3mx0Q0lAiXrNuOoV5XTEGA3K f8YQ== Received: by 10.180.20.204 with SMTP id p12mr3900338wie.7.1345129160259; Thu, 16 Aug 2012 07:59:20 -0700 (PDT) Received: from teal.hq.k1024.org (46-126-106-189.dynamic.hispeed.ch. [46.126.106.189]) by mx.google.com with ESMTPS id t8sm4233446wiy.3.2012.08.16.07.59.18 (version=TLSv1/SSLv3 cipher=AES128-SHA); Thu, 16 Aug 2012 07:59:18 -0700 (PDT) Received: from ruru.hq.k1024.org (ruru.hq.k1024.org [10.1.167.27]) by teal.hq.k1024.org (Postfix) with ESMTP id 04F5F205CB7; Thu, 16 Aug 2012 16:59:17 +0200 (CEST) Received: by ruru.hq.k1024.org (Postfix, from userid 4004) id 7DA9F62B473; Thu, 16 Aug 2012 16:58:36 +0200 (CEST) Date: Thu, 16 Aug 2012 16:58:36 +0200 From: Iustin Pop To: qemu-devel@nongnu.org Message-ID: <20120816145836.GA6793@hq.k1024.org> MIME-Version: 1.0 Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQnV7mCaGcS1NacNXEY2V2ZAKerHmi3gLulJuryP0YFvfaDsNgxYxSkr34TLI9Ha8ywUdtc9 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.181 X-Mailman-Approved-At: Thu, 16 Aug 2012 13:42:58 -0400 Cc: Kevin Wolf Subject: [Qemu-devel] [PATCH] block: handle filenames with colons better X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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 --- 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)