X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org Date: Tue, 29 Jun 2010 10:43:37 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Regression in .exe extension handling Message-ID: <20100629084337.GA8163@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <1277766496.7412.18.camel@YAAKOV04> <4C292D35.6000005@redhat.com> <1277780070.7412.231.camel@YAAKOV04> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1277780070.7412.231.camel@YAAKOV04> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Jun 28 21:54, Yaakov S wrote: > On Mon, 2010-06-28 at 17:16 -0600, Eric Blake wrote: > > The problem is here - should install be open()ing "foo" (the script) or > > "foo.exe" (the executable) as the source file for copying into bar/foo? > > Since it is never a good idea to have both an .exe and a script of the > > same name in the same directory, is this really a regression, or just > > bad behavior on mono's part? > > This is a regression: it worked just fine with earlier 1.7.x releases. > > > Remember, libtool was recently changed to avoid exactly this ambiguity. > > This is different: neither the wrapper nor assembly are executed in the > builddir; they are just created there and installed into different > locations. > > > Or should I be trying to patch coreutils (and/or someone patch cygwin1.dll) > > to try harder to open the script instead of the .exe when the suffix-less > > file conflicts with the .exe? > > It's definitely a bug (or two) somewhere: > > * "install foo" correctly installs 'foo' but the presence of foo.exe > apparently fools something to add the .exe. > > * the .exe is being added when the file is clearly not a PE executable, > nor a link thereto. > > Whether these bugs are coming from coreutils or cygwin, or both, I do > not know. It doesn't look like a problem in Cygwin. Strace shows there's an open("bar/foo.exe") call to create the file. I assume it's the logic in install along the lines of stat("foo") shows that "foo" exists? yes -> stat("foo.exe") shows that "foo.exe" exists? yes -> so the original file is called "foo.exe". Maybe the test should check for the entire struct stat to be identical before making this decision? Just an idea... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple