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