From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1W4aQB-0006SU-Pm for mharc-grub-devel@gnu.org; Sat, 18 Jan 2014 13:15:03 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4aQ2-0006OO-Eo for grub-devel@gnu.org; Sat, 18 Jan 2014 13:15:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4aPu-0002dd-1H for grub-devel@gnu.org; Sat, 18 Jan 2014 13:14:54 -0500 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:65193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4aPt-0002cu-QU for grub-devel@gnu.org; Sat, 18 Jan 2014 13:14:45 -0500 Received: by mail-ea0-f177.google.com with SMTP id n15so2343467ead.8 for ; Sat, 18 Jan 2014 10:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=IIFmXhcEzWHB+IhjVK6u1NTlsemqqjVXbNjiWEDPX2g=; b=eOXUqjsDK09UW0aS4ZNvP6Dm1iwH9F0IMcDYZP3CSiws+1IPOo3iNmEo4mcAvVnQUr 42qWS1Ey069UC4+Fjxyv2mBuaVNj2tY0Q8/kn6YcJ3WIkQOjXgwL+raPoECrgGMc7rrB cm9d1/UVuerowyNtE2anyyby+A26ZE2QWldNTjkPn5FcWeISafOSV0ySnM8o5zcHZ9rN THahJbr+Wx868/kvvrmI4shpqWv+7UYY+IitbEe5R0GO/NPNzBvJODZ2aLEoQYdcX2NW H4qVSuRgaafU76AYF49Y2zQH1RuL1+DkQwyMqGiDnpuQ2AIP8oyQeIO7YMS9gVTWeGIK sIYw== X-Received: by 10.14.115.8 with SMTP id d8mr2609423eeh.83.1390068884910; Sat, 18 Jan 2014 10:14:44 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id 46sm20816181ees.4.2014.01.18.10.14.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jan 2014 10:14:44 -0800 (PST) Message-ID: <52DAC493.7060104@gmail.com> Date: Sat, 18 Jan 2014 19:14:43 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH] fix removal of {cpu,machine} links on mingw/msys References: <1388224711-10010-1-git-send-email-arvidjaar@gmail.com> In-Reply-To: <1388224711-10010-1-git-send-email-arvidjaar@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="p6t5svmcGA2UCKKjxXBDin1nQ9e84M7cm" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::231 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 18:15:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p6t5svmcGA2UCKKjxXBDin1nQ9e84M7cm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28.12.2013 10:58, Andrey Borzenkov wrote: > At least on Windows 2003 using "ln -s dir1 dir2" in msys shell succeeds= , > but results in what looks like hard link. Subsequent "rm -f dir2" (e.g.= > during second config.status invocation) fails. Check that we also can > remove link to directory. >=20 > Make it more clear in message that we are checking "ln -s". >=20 Is there a way to reliably remove result of such test? We don't want to leave a weird file after the test behind. Perhaps rm -rf since we know that we test with newly-created directory? > --- > acinclude.m4 | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/acinclude.m4 b/acinclude.m4 > index 32d5477..b2bb88d 100644 > --- a/acinclude.m4 > +++ b/acinclude.m4 > @@ -418,15 +418,15 @@ else > [fi] > ]) > =20 > -dnl Check if ln can handle directories properly (mingw). > +dnl Check if ln -s can handle directories properly (mingw). > AC_DEFUN([grub_CHECK_LINK_DIR],[ > -AC_MSG_CHECKING([whether ln can handle directories properly]) > +AC_MSG_CHECKING([whether ln -s can handle directories properly]) > [mkdir testdir 2>/dev/null > case $srcdir in > [\\/$]* | ?:[\\/]* ) reldir=3D$srcdir/include/grub/util ;; > *) reldir=3D../$srcdir/include/grub/util ;; > esac > -if ln -s $reldir testdir/util 2>/dev/null ; then] > +if ln -s $reldir testdir/util 2>/dev/null && rm -f testdir/util 2>/dev= /null ; then] > AC_MSG_RESULT([yes]) > [link_dir=3Dyes > else >=20 --p6t5svmcGA2UCKKjxXBDin1nQ9e84M7cm 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: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlLaxJMACgkQmBXlbbo5nOtUgwD+JpQXaJSzqZhB1QB4wOsbABuo 8G8OnvcMXRiwv77yP3oBAJRAcnteQjjHK0MjUhtYbXWstYG2CWo8VBrMQqzIuY5h =7Og1 -----END PGP SIGNATURE----- --p6t5svmcGA2UCKKjxXBDin1nQ9e84M7cm--