Regression in .exe extension handling

Regression in .exe extension handling

[Yaakov (Cygwin/X)]

It is not unusual for mono packages to create a wrapper script (to be
installed in PATH) in the same directory as an assembly (which has .exe
suffix and is installed out of PATH), which uncovered a regression using
the 20100622 snapshot:

echo script > foo
echo executable > foo.exe
mkdir bar
install foo bar/foo
ls bar
cat bar/foo

You will see that bar/foo.exe is created but it's really the 'script'
foo.


Yaakov



--
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

Re: Regression in .exe extension handling

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On 06/28/2010 05:08 PM, Yaakov (Cygwin/X) wrote:
> It is not unusual for mono packages to create a wrapper script (to be
> installed in PATH) in the same directory as an assembly (which has .exe
> suffix and is installed out of PATH), which uncovered a regression using
> the 20100622 snapshot:
> 
> echo script > foo
> echo executable > foo.exe
> mkdir bar
> install foo bar/foo

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?  Remember, libtool was recently changed to
avoid exactly this ambiguity.  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?

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Regression in .exe extension handling

[Christopher Faylor]

On Mon, Jun 28, 2010 at 05:16:05PM -0600, Eric Blake wrote:
>On 06/28/2010 05:08 PM, Yaakov (Cygwin/X) wrote:
>> It is not unusual for mono packages to create a wrapper script (to be
>> installed in PATH) in the same directory as an assembly (which has .exe
>> suffix and is installed out of PATH), which uncovered a regression using
>> the 20100622 snapshot:
>> 
>> echo script > foo
>> echo executable > foo.exe
>> mkdir bar
>> install foo bar/foo
>
>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?  Remember, libtool was recently changed to
>avoid exactly this ambiguity.  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?

Is the dll "misbehaving" here or the install program?

cgf

--
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

Re: Regression in .exe extension handling

[Cyrille Lefevre]

Le 29/06/2010 01:16, Eric Blake a écrit :
> On 06/28/2010 05:08 PM, Yaakov (Cygwin/X) wrote:
>> It is not unusual for mono packages to create a wrapper script (to be
>> installed in PATH) in the same directory as an assembly (which has .exe
>> suffix and is installed out of PATH), which uncovered a regression using
>> the 20100622 snapshot:
>>
>> echo script>  foo
>> echo executable>  foo.exe
>> mkdir bar
>> install foo bar/foo
>
> 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?

well, how about the use of the O_BINARY flag to make the decision ?
if both files exists and O_BINARY is specified, open the .exe one,
the other one otherwise ?

> 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

why? many scripts use this assertion, they usually are called 
wrappers... :-)

> bad behavior on mono's part?  Remember, libtool was recently changed to
> avoid exactly this ambiguity.  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?

easy for reading (':' or '#!', rem, etc. :-), does "file" is implemented 
as part of the cygwin1.dll. not so easy for writing...

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists@laposte.net



--
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

Re: Regression in .exe extension handling

[Yaakov (Cygwin/X)]

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.


Yaakov



--
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

Re: Regression in .exe extension handling

[Corinna Vinschen]

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

Re: Regression in .exe extension handling

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On 06/29/2010 02:43 AM, Corinna Vinschen wrote:
>> 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...

Most likely, the hole is in coreutils' exe magic.  Looks like I'll be
working on a coreutils-8.5-3 today...

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Regression in .exe extension handling

[Yaakov (Cygwin/X)]

On Tue, 2010-06-29 at 07:54 -0600, Eric Blake wrote:
> Most likely, the hole is in coreutils' exe magic.  Looks like I'll be
> working on a coreutils-8.5-3 today...

Since apparently that hasn't happened yet, let me add that the same
thing is not limited to files, but happens with a directory as well:

mkdir foo bar
touch bar/baz
touch bar.exe
mv bar foo
find foo

Once again, the right 'bar' is chosen by 'mv' but the .exe is
erroneously appended due to the presence of bar.exe.


Yaakov



--
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