From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXGyJ-0001cj-P9 for qemu-devel@nongnu.org; Mon, 07 Apr 2014 17:20:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXGyD-0006nC-0G for qemu-devel@nongnu.org; Mon, 07 Apr 2014 17:20:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXGyC-0006mz-Ny for qemu-devel@nongnu.org; Mon, 07 Apr 2014 17:20:44 -0400 Message-ID: <53431691.3050102@redhat.com> Date: Mon, 07 Apr 2014 15:20:17 -0600 From: Eric Blake MIME-Version: 1.0 References: <1396716195-12563-1-git-send-email-junmuzi@gmail.com> In-Reply-To: <1396716195-12563-1-git-send-email-junmuzi@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gXEl08nTAHkfNOWe8EhcOXbQk2htxehe4" Subject: Re: [Qemu-devel] [PATCH] snapshot: fixed bdrv_get_full_backing_filename can not get correct full_backing_filename List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jun Li , kwolf@redhat.com, stefanha@redhat.com, juli@redhat.com Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gXEl08nTAHkfNOWe8EhcOXbQk2htxehe4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/05/2014 10:43 AM, Jun Li wrote: > This patch fixed the following bug: > https://bugzilla.redhat.com/show_bug.cgi?id=3D1084302 . > path_combine can not calculate the correct full path name for backing_f= ile. > Such as: > create a snapshot chain: > sn2->sn1->$BASE_IMG > backing file is : /home/wookpecker/img.qcow2 > sn1 : /home/woodpecker/tmp/sn1 > sn2 : /home/woodpecker/tmp/sn2 > when create sn2, path_combine can not got a correct path for $BASE_IMG.= >=20 > Signed-off-by: Jun Li > --- > block.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/block.c b/block.c > index 990a754..2519f68 100644 > --- a/block.c > +++ b/block.c > @@ -307,7 +307,7 @@ void bdrv_get_full_backing_filename(BlockDriverStat= e *bs, char *dest, size_t sz) > if (bs->backing_file[0] =3D=3D '\0' || path_has_protocol(bs->backi= ng_file)) { > pstrcpy(dest, sz, bs->backing_file); > } else { > - path_combine(dest, sz, bs->filename, bs->backing_file); > + realpath(bs->backing_file, dest); Ouch - I think this does the wrong thing in the presence of symlinks. VDSM is an existing client that likes to create symlinks to qcow2 files, where the backing chain uses relative names that work ONLY if you resolve them in relation to the directory containing the symlink. As an example, if I have the following tree: /path/to/base - qcow2 file /path/to/mid - qcow2 file, backing of '../dir/baselink' /path/to/top - qcow2 file, backing of '../dir/midlink' /path/to/dir/baselink - symlink to '../base' /path/to/dir/midlink - symlink to '../mid' /path/to/dir/toplink - symlink to '../top' then changing directories to '/path/to/dir' and opening './toplink' should correctly find ../dir/midlink and ../dir/../dir/baselink (aka =2E./mid and ../top) as its backing chain. But if you use realpath() on the results, you will get '/path/to/mid' as the backing file of 'toplink' (that is, the symlink is canonicalized), and when you then go to find the backing file, '/path/to/../dir/baselink' does NOT exist (by using realpath, you are starting the search for the relative backing file from the wrong directory). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --gXEl08nTAHkfNOWe8EhcOXbQk2htxehe4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTQxaRAAoJEKeha0olJ0NqYNEIAKUk3qry541J2HDVsWCp3s6E Tfm7aTSJKz/yj8JVVPcp2IRhb/XvYElyTJwTxF7xZtbrR96wVok+w8cLziKai5NM xnoWyr9K06scxa8H+8szWCEJvm2Q159qQ9FwJ3jS1vHFXfgEIexYXxtrnwijwAi4 MTxeHWgh+z0TRwoE6iP80xBGfFcSQaG0EM3WSrgHVjFHKn8IT8DTVeVN+8eFQYua L7Eu/OKTi/BtjWsLwNQFeSAhPDHc2+oZFjxZ+SHq2uGx08b4VKSTws0vSJ/P8Gs0 DsKTWHNmL+fIKEkPTBTLMsfg4yViIYWaXsWsfIAZsVoVNL5LFomHUQq6ccAk/Gc= =LB/a -----END PGP SIGNATURE----- --gXEl08nTAHkfNOWe8EhcOXbQk2htxehe4--