tar deletes .exe files on extraction (again)

tar deletes .exe files on extraction (again)

[Steve Atkins]

In the process of trying to build Qt on Windows in a cygwin shell, I've discovered that neither tar nor unzip will work reliably under Cygwin - untaring an archive will not correctly create the files that the archive contains. The "configure.exe" that's required to build Qt is never extracted from the tarball.

The problem is that the cygwin filesystem shims consider "configure" and "configure.exe" to be almost the same, despite their having different filenames, so when tar extracts an archive containing both it ends up deleting the existing "configure.exe" when it creates "configure".

This was discussed a couple of years ago - http://cygwin.com/ml/cygwin/2009-08/msg00293.html - and the conclusion seemed to be that cygwin was working as designed, and the user just shouldn't ever be doing anything that requires both "foo" and "foo.exe" under cygwin, and that if they do want to do that, they probably shouldn't be using cygwin.

That seems like a fairly nasty limitation / bug, and makes use of the cygwin shell a bit too brittle to rely on for build automation - I'm wondering if anyone knows if there's been any change in the situation since then?

Cheers,
  Steve


--
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: tar deletes .exe files on extraction (again)

[Larry Hall (Cygwin)]

On 9/22/2011 4:57 PM, Steve Atkins wrote:
> In the process of trying to build Qt on Windows in a cygwin shell, I've
> discovered that neither tar nor unzip will work reliably under Cygwin -
> untaring an archive will not correctly create the files that the archive
> contains. The "configure.exe" that's required to build Qt is never extracted
> from the tarball.
>
> The problem is that the cygwin filesystem shims consider "configure" and
> "configure.exe" to be almost the same, despite their having different
> filenames, so when tar extracts an archive containing both it ends up
> deleting the existing "configure.exe" when it creates "configure".
>
> This was discussed a couple of years ago -
> http://cygwin.com/ml/cygwin/2009-08/msg00293.html - and the conclusion
> seemed to be that cygwin was working as designed, and the user just
> shouldn't ever be doing anything that requires both "foo" and "foo.exe"
> under cygwin, and that if they do want to do that, they probably shouldn't
> be using cygwin.
>
> That seems like a fairly nasty limitation / bug, and makes use of the
> cygwin shell a bit too brittle to rely on for build automation - I'm
> wondering if anyone knows if there's been any change in the situation since
> then?

No, no change and probably not likely to be anytime soon.  By using the
Windows build environment for QT, you're trying to force a Windowsism into
Cygwin's POSIX environment.  The transparency of the ".exe" extension is
already a concession to a Windowsism, namely that executables must have a
.exe extension.  Cygwin needed to support this one though to make allot of
POSIX scripts work without alteration.  That may cause breakage in corner
cases like the QT Windows build environment but that's the (far) lesser of
two evils.  Cygwin's striving to provide a POSIX environment in a Win32
environment after all.  I know nothing about the QT build environment but
from what you've said, it doesn't sound like it's assuming a POSIX
environment for building on Windows.  I'd recommend sticking with tools
that conform to the Windows requirements if you're building for Windows.

That said, going forward, there may come a day when all Cygwin executables
no longer have the .exe extension, which was really an interoperability
concession to Windows 9x/Me platforms.  Cygwin 1.7 doesn't support 9x/Me, so 
the concession is now largely a historical one and could possibly be
changed.  But even if it were to happen, it would be a big undertaking due
to the number of Cygwin packages that would be affected (i.e. all).  It
would take quite a while to trickle down to the majority of packages.  And
only at that point might it make sense to remove the transparent handling
of exe.  So that brings me back to my opening statement. :-)

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: tar deletes .exe files on extraction (again)

[Ryan Johnson]

On 22/09/2011 9:56 PM, Larry Hall (Cygwin) wrote:
> On 9/22/2011 4:57 PM, Steve Atkins wrote:
>> In the process of trying to build Qt on Windows in a cygwin shell, I've
>> discovered that neither tar nor unzip will work reliably under Cygwin -
>> untaring an archive will not correctly create the files that the archive
>> contains. The "configure.exe" that's required to build Qt is never 
>> extracted
>> from the tarball.
>>
>> The problem is that the cygwin filesystem shims consider "configure" and
>> "configure.exe" to be almost the same, despite their having different
>> filenames, so when tar extracts an archive containing both it ends up
>> deleting the existing "configure.exe" when it creates "configure".
>>
>> This was discussed a couple of years ago -
>> http://cygwin.com/ml/cygwin/2009-08/msg00293.html - and the conclusion
>> seemed to be that cygwin was working as designed, and the user just
>> shouldn't ever be doing anything that requires both "foo" and "foo.exe"
>> under cygwin, and that if they do want to do that, they probably 
>> shouldn't
>> be using cygwin.
>>
>> That seems like a fairly nasty limitation / bug, and makes use of the
>> cygwin shell a bit too brittle to rely on for build automation - I'm
>> wondering if anyone knows if there's been any change in the situation 
>> since
>> then?
>
> No, no change and probably not likely to be anytime soon.  By using the
> Windows build environment for QT, you're trying to force a Windowsism 
> into
> Cygwin's POSIX environment.  The transparency of the ".exe" extension is
> already a concession to a Windowsism, namely that executables must have a
> .exe extension.  Cygwin needed to support this one though to make 
> allot of
> POSIX scripts work without alteration.  That may cause breakage in corner
> cases like the QT Windows build environment but that's the (far) 
> lesser of
> two evils.  Cygwin's striving to provide a POSIX environment in a Win32
> environment after all.  I know nothing about the QT build environment but
> from what you've said, it doesn't sound like it's assuming a POSIX
> environment for building on Windows.  I'd recommend sticking with tools
> that conform to the Windows requirements if you're building for Windows.
>
> That said, going forward, there may come a day when all Cygwin 
> executables
> no longer have the .exe extension, which was really an interoperability
> concession to Windows 9x/Me platforms.  Cygwin 1.7 doesn't support 
> 9x/Me, so the concession is now largely a historical one and could 
> possibly be
> changed.  But even if it were to happen, it would be a big undertaking 
> due
> to the number of Cygwin packages that would be affected (i.e. all).  It
> would take quite a while to trickle down to the majority of packages.  
> And
> only at that point might it make sense to remove the transparent handling
> of exe.  So that brings me back to my opening statement. :-)
Wild speculation here...

A quick test shows that ./a indeed works fine inside cygwin whether the 
'.exe' is present or not, though it would be a little challenging invoke 
such binaries directly from Windows.

So... how hard would it be to provide 
"CYGWIN=(no)disabletransparent_exe"?*** There could a very simple 
utility, similar to rebaseall, which strips the .exe extension from 
cygwin executables (identifiable from cygcheck or their presence in 
standard paths), and which accepts additional paths to clean up. People 
needing the functionality would be responsible run the utility properly 
(after installing new packages, don't mess with Windows paths, etc.).

That would require no changes to any package to give the desired 
behavior, and as packages change they would just fit right in (no .exe 
in the package ==> no fuss).

Of course, SHTDI...

Ryan

*** The old, removed "transparent_exe" has the wrong boolean sense to 
work the correct way by default

--
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: tar deletes .exe files on extraction (again)

[Andrew DeFaria]

On 09/23/11 07:55, Ryan Johnson wrote:
> On 22/09/2011 9:56 PM, Larry Hall (Cygwin) wrote:
>> On 9/22/2011 4:57 PM, Steve Atkins wrote:
>>> In the process of trying to build Qt on Windows in a cygwin shell, I've
>>> discovered that neither tar nor unzip will work reliably under Cygwin -
>>> untaring an archive will not correctly create the files that the 
>>> archive
>>> contains. The "configure.exe" that's required to build Qt is never 
>>> extracted
>>> from the tarball.
>>>
>>> The problem is that the cygwin filesystem shims consider "configure" 
>>> and
>>> "configure.exe" to be almost the same, despite their having different
>>> filenames, so when tar extracts an archive containing both it ends up
>>> deleting the existing "configure.exe" when it creates "configure".
>>>
>>> This was discussed a couple of years ago -
>>> http://cygwin.com/ml/cygwin/2009-08/msg00293.html - and the conclusion
>>> seemed to be that cygwin was working as designed, and the user just
>>> shouldn't ever be doing anything that requires both "foo" and "foo.exe"
>>> under cygwin, and that if they do want to do that, they probably 
>>> shouldn't
>>> be using cygwin.
>>>
>>> That seems like a fairly nasty limitation / bug, and makes use of the
>>> cygwin shell a bit too brittle to rely on for build automation - I'm
>>> wondering if anyone knows if there's been any change in the 
>>> situation since
>>> then?
>>
>> No, no change and probably not likely to be anytime soon.  By using the
>> Windows build environment for QT, you're trying to force a Windowsism 
>> into
>> Cygwin's POSIX environment.  The transparency of the ".exe" extension is
>> already a concession to a Windowsism, namely that executables must 
>> have a
>> .exe extension.  Cygwin needed to support this one though to make 
>> allot of
>> POSIX scripts work without alteration.  That may cause breakage in 
>> corner
>> cases like the QT Windows build environment but that's the (far) 
>> lesser of
>> two evils.  Cygwin's striving to provide a POSIX environment in a Win32
>> environment after all.  I know nothing about the QT build environment 
>> but
>> from what you've said, it doesn't sound like it's assuming a POSIX
>> environment for building on Windows.  I'd recommend sticking with tools
>> that conform to the Windows requirements if you're building for Windows.
>>
>> That said, going forward, there may come a day when all Cygwin 
>> executables
>> no longer have the .exe extension, which was really an interoperability
>> concession to Windows 9x/Me platforms.  Cygwin 1.7 doesn't support 
>> 9x/Me, so the concession is now largely a historical one and could 
>> possibly be
>> changed.  But even if it were to happen, it would be a big 
>> undertaking due
>> to the number of Cygwin packages that would be affected (i.e. all).  It
>> would take quite a while to trickle down to the majority of 
>> packages.  And
>> only at that point might it make sense to remove the transparent 
>> handling
>> of exe.  So that brings me back to my opening statement. :-)
> Wild speculation here...
>
> A quick test shows that ./a indeed works fine inside cygwin whether 
> the '.exe' is present or not, though it would be a little challenging 
> invoke such binaries directly from Windows.
>
> So... how hard would it be to provide 
> "CYGWIN=(no)disabletransparent_exe"?*** There could a very simple 
> utility, similar to rebaseall, which strips the .exe extension from 
> cygwin executables (identifiable from cygcheck or their presence in 
> standard paths), and which accepts additional paths to clean up. 
> People needing the functionality would be responsible run the utility 
> properly (after installing new packages, don't mess with Windows 
> paths, etc.).
>
> That would require no changes to any package to give the desired 
> behavior, and as packages change they would just fit right in (no .exe 
> in the package ==> no fuss).
>
> Of course, SHTDI...
>
> Ryan
>
> *** The old, removed "transparent_exe" has the wrong boolean sense to 
> work the correct way by default
>
What do you do about say, Foo.c and foo.c?
-- 
Andrew DeFaria <http://defaria.com>
Give a person a fish and you feed them for a day; teach that person to 
use the Internet and they won't bother you for weeks.


--
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: tar deletes .exe files on extraction (again)

[Peter Rosin]

Andrew DeFaria wrote On 2011-09-23 17:34:
> On 09/23/11 07:55, Ryan Johnson wrote:
>> *** The old, removed "transparent_exe" has the wrong boolean sense to
>> work the correct way by default
>>
> What do you do about say, Foo.c and foo.c?

How about looking in the faq?

http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

Cheers,
Peter

--
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: tar deletes .exe files on extraction (again)

[Steve Atkins]

On Sep 23, 2011, at 8:34 AM, Andrew DeFaria wrote:

> On 09/23/11 07:55, Ryan Johnson wrote:
>> 
>> Wild speculation here...
>> 
>> A quick test shows that ./a indeed works fine inside cygwin whether the '.exe' is present or not, though it would be a little challenging invoke such binaries directly from Windows.
>> 
>> So... how hard would it be to provide "CYGWIN=(no)disabletransparent_exe"?*** There could a very simple utility, similar to rebaseall, which strips the .exe extension from cygwin executables (identifiable from cygcheck or their presence in standard paths), and which accepts additional paths to clean up. People needing the functionality would be responsible run the utility properly (after installing new packages, don't mess with Windows paths, etc.).
>> 
>> That would require no changes to any package to give the desired behavior, and as packages change they would just fit right in (no .exe in the package ==> no fuss).
>> 
>> Of course, SHTDI...
>> 
>> Ryan
>> 
>> *** The old, removed "transparent_exe" has the wrong boolean sense to work the correct way by default
>> 
> What do you do about say, Foo.c and foo.c?

The same as you do now on cygwin and on other case-preserving but case-insensitive filesystems - treat them as identical. That's still a little annoying, but not uncommon on unix-ish environments (OS X as one common example) so people already are aware of it and work around it.

Cheers,
  Steve


--
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: tar deletes .exe files on extraction (again)

[Andrew DeFaria]

On 9/23/2011 9:14 AM, Steve Atkins wrote:
> On Sep 23, 2011, at 8:34 AM, Andrew DeFaria wrote:
>
>> On 09/23/11 07:55, Ryan Johnson wrote:
>>> Wild speculation here...
>>>
>>> A quick test shows that ./a indeed works fine inside cygwin whether the '.exe' is present or not, though it would be a little challenging invoke such binaries directly from Windows.
>>>
>>> So... how hard would it be to provide "CYGWIN=(no)disabletransparent_exe"?*** There could a very simple utility, similar to rebaseall, which strips the .exe extension from cygwin executables (identifiable from cygcheck or their presence in standard paths), and which accepts additional paths to clean up. People needing the functionality would be responsible run the utility properly (after installing new packages, don't mess with Windows paths, etc.).
>>>
>>> That would require no changes to any package to give the desired behavior, and as packages change they would just fit right in (no .exe in the package ==>  no fuss).
>>>
>>> Of course, SHTDI...
>>>
>>> Ryan
>>>
>>> *** The old, removed "transparent_exe" has the wrong boolean sense to work the correct way by default
>>>
>> What do you do about say, Foo.c and foo.c?
> The same as you do now on cygwin and on other case-preserving but case-insensitive filesystems - treat them as identical. That's still a little annoying, but not uncommon on unix-ish environments (OS X as one common example) so people already are aware of it and work around it.
>
> Cheers,
>    Steve
My point, obviously missed, was that I thought that the issue here was 
that if you untar a tar which contains say a.exe and a as two different 
files the later one will overwrite the former due to the way that Cygwin 
treats files that end in .exe. Wouldn't you have a similar problem if 
you had Foo.c and foo.c in the tar image? (Note I didn't know about that 
registry setting which is interesting and which I'd venture to guess 
nobody runs with).

If people "work around" the Foo.c/foo.c issue, presumably by renaming 
one of the files, couldn't they likewise "work around" the a.exe/a issue?
-- 
Andrew DeFaria <http://defaria.com>
Reality is a crutch for people who can't handle drugs.


--
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: tar deletes .exe files on extraction (again)

[Steve Atkins]

On Sep 23, 2011, at 10:41 AM, Andrew DeFaria wrote:

> On 9/23/2011 9:14 AM, Steve Atkins wrote:
>> On Sep 23, 2011, at 8:34 AM, Andrew DeFaria wrote:
>> 
>>> On 09/23/11 07:55, Ryan Johnson wrote:
>>>> Wild speculation here...
>>>> 
>>>> A quick test shows that ./a indeed works fine inside cygwin whether the '.exe' is present or not, though it would be a little challenging invoke such binaries directly from Windows.
>>>> 
>>>> So... how hard would it be to provide "CYGWIN=(no)disabletransparent_exe"?*** There could a very simple utility, similar to rebaseall, which strips the .exe extension from cygwin executables (identifiable from cygcheck or their presence in standard paths), and which accepts additional paths to clean up. People needing the functionality would be responsible run the utility properly (after installing new packages, don't mess with Windows paths, etc.).
>>>> 
>>>> That would require no changes to any package to give the desired behavior, and as packages change they would just fit right in (no .exe in the package ==>  no fuss).
>>>> 
>>>> Of course, SHTDI...
>>>> 
>>>> Ryan
>>>> 
>>>> *** The old, removed "transparent_exe" has the wrong boolean sense to work the correct way by default
>>>> 
>>> What do you do about say, Foo.c and foo.c?
>> The same as you do now on cygwin and on other case-preserving but case-insensitive filesystems - treat them as identical. That's still a little annoying, but not uncommon on unix-ish environments (OS X as one common example) so people already are aware of it and work around it.
>> 
>> Cheers,
>>   Steve
> My point, obviously missed, was that I thought that the issue here was that if you untar a tar which contains say a.exe and a as two different files the later one will overwrite the former due to the way that Cygwin treats files that end in .exe. Wouldn't you have a similar problem if you had Foo.c and foo.c in the tar image? (Note I didn't know about that registry setting which is interesting and which I'd venture to guess nobody runs with).
> 
> If people "work around" the Foo.c/foo.c issue, presumably by renaming one of the files, couldn't they likewise "work around" the a.exe/a issue?

I'm talking about developers of applications, not cygwin-using end users. The developers could work around it (by not including .exe bootstrap files in cross-platform packages or being careful with naming), but they don't because it's not an issue that would ever occur to them, unlike case-insensitivity. 

Many systems are case-insensitive - and, more importantly, at least one system that's commonly used by developers is - so most software is developed and packaged with that in mind. Case insensitivity is a well understood issue. Only one system, cygwin, considers foo and foo.exe to be identical. It's a niche environment, and not used by many developers who target a unix-style environment, so most developers packaging software will not be aware of the issue and won't work around it. 

Treating "foo" and "foo.exe" as equivalent is a very non-unixy thing to do ("everything is a file, and the name of the file isn't important to the kernel") so it's particularly surprising behaviour on a system that otherwise looks quite like a unix environment.

(I'd assumed that cygwin worked by intercepting execve(), and it hadn't even occurred to me that it would modify filesystem access at a coarser level than that until I started diagnosing apparent bugs in tar).

It's not a serious problem, of course - but it does mean that the most widely used cross-platform GUI library cannot be unpacked on cygwin and built from source without jumping through hoops. Given that the cygwin environment is very attractive to cross-platform developers I'm betting I'm not the first person who has been burned by this, and won't be the last.

I'm not sure what the best thing to do about it is - but even a user level patch to tar and unzip to warn when it's done something unexpected would have saved me quite a lot of grief.

Cheers,
  Steve


--
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: tar deletes .exe files on extraction (again)

[Andrew DeFaria]

On 9/23/2011 11:26 AM, Steve Atkins wrote:
> I'm talking about developers of applications, not cygwin-using end users. The developers could work around it (by not including .exe bootstrap files in cross-platform packages or being careful with naming), but they don't because it's not an issue that would ever occur to them, unlike case-insensitivity.
>
> Many systems are case-insensitive
Really? Aside from Windows what other systems are case insensitive?
>   - and, more importantly, at least one system that's commonly used by developers is - so most software is developed and packaged with that in mind. Case insensitivity is a well understood issue. Only one system, cygwin, considers foo and foo.exe to be identical.
And as far as I can tell, only one system Windows, is case insensitive 
WRT filenames. Coincidence? I don't think so! ;-)
>   It's a niche environment, and not used by many developers who target a unix-style environment, so most developers packaging software will not be aware of the issue and won't work around it.
I don't think I've met many developers who target a Unix-style 
environment who did not know about Cygwin and, if forced to use Windows, 
use Cygwin. Granted the foo vs. foo.exe thing is a bit obscure, but I'd 
say that a Unix developer actually naming something .exe is also pretty 
rare.
> Treating "foo" and "foo.exe" as equivalent is a very non-unixy thing to do
Neither is naming some thing with a .exe at the end!
> ("everything is a file, and the name of the file isn't important to the kernel") so it's particularly surprising behaviour on a system that otherwise looks quite like a unix environment.
>
> (I'd assumed that cygwin worked by intercepting execve(), and it hadn't even occurred to me that it would modify filesystem access at a coarser level than that until I started diagnosing apparent bugs in tar).
>
> It's not a serious problem, of course - but it does mean that the most widely used cross-platform GUI library cannot be unpacked on cygwin and built from source without jumping through hoops. Given that the cygwin environment is very attractive to cross-platform developers I'm betting I'm not the first person who has been burned by this, and won't be the last.
So why don't you ask them to fix it? I mean what do they need a foo and 
a  foo.exe for anyway?
> I'm not sure what the best thing to do about it is - but even a user level patch to tar and unzip to warn when it's done something unexpected would have saved me quite a lot of grief.
-- 
Andrew DeFaria <http://defaria.com>
Don't drink and drive... You might hit a bump and spill your drink.


--
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: tar deletes .exe files on extraction (again)

[Steve Atkins]

On Sep 23, 2011, at 11:46 AM, Andrew DeFaria wrote:

> On 9/23/2011 11:26 AM, Steve Atkins wrote:
>> I'm talking about developers of applications, not cygwin-using end users. The developers could work around it (by not including .exe bootstrap files in cross-platform packages or being careful with naming), but they don't because it's not an issue that would ever occur to them, unlike case-insensitivity.
>> 
>> Many systems are case-insensitive
> Really? Aside from Windows what other systems are case insensitive?

The default HFS+ on OS X is the big one for unixy developers (but there's also OS/2 HPFS, ISO9660, most of the Amiga filesystems, VMS and I think RT-11 :) ). 

>>  - and, more importantly, at least one system that's commonly used by developers is - so most software is developed and packaged with that in mind. Case insensitivity is a well understood issue. Only one system, cygwin, considers foo and foo.exe to be identical.
> And as far as I can tell, only one system Windows, is case insensitive WRT filenames. Coincidence? I don't think so! ;-)

>>  It's a niche environment, and not used by many developers who target a unix-style environment, so most developers packaging software will not be aware of the issue and won't work around it.
> I don't think I've met many developers who target a Unix-style environment who did not know about Cygwin and, if forced to use Windows, use Cygwin. Granted the foo vs. foo.exe thing is a bit obscure, but I'd say that a Unix developer actually naming something .exe is also pretty rare.

For a pure unix developer, sure. For a cross-platform developer maybe less so. 

>> Treating "foo" and "foo.exe" as equivalent is a very non-unixy thing to do
> Neither is naming some thing with a .exe at the end!

Sure it is. I can use any string I like to name a file! :)

(And I have seen it done with some CAD apps in the dim and distant past where the actual executable was /opt/foo/bin/bar.exe which was called from a wrapper script shell /opt/foo/bin/bar. Slightly odd, sure, but not entirely silly.)

>> ("everything is a file, and the name of the file isn't important to the kernel") so it's particularly surprising behaviour on a system that otherwise looks quite like a unix environment.
>> 
>> (I'd assumed that cygwin worked by intercepting execve(), and it hadn't even occurred to me that it would modify filesystem access at a coarser level than that until I started diagnosing apparent bugs in tar).
>> 
>> It's not a serious problem, of course - but it does mean that the most widely used cross-platform GUI library cannot be unpacked on cygwin and built from source without jumping through hoops. Given that the cygwin environment is very attractive to cross-platform developers I'm betting I'm not the first person who has been burned by this, and won't be the last.
> So why don't you ask them to fix it?

Because it's not their bug, and it's something that'll pop up elsewhere too. (Note that I'm not asking anyone working on cygwin to fix it either, just reporting the issue, asking if my understanding of the bug is correct and current, then sticking around for the conversation.)

> I mean what do they need a foo and a  foo.exe for anyway?

configure is a shell script that does what configure always does. configure.exe is a windows binary that does much the same thing for a windows platform.

Cheers,
  Steve


--
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: tar deletes .exe files on extraction (again)

[Andrew DeFaria]

On 9/23/2011 12:07 PM, Steve Atkins wrote:
> On Sep 23, 2011, at 11:46 AM, Andrew DeFaria wrote:
>
>> On 9/23/2011 11:26 AM, Steve Atkins wrote:
>>> I'm talking about developers of applications, not cygwin-using end users. The developers could work around it (by not including .exe bootstrap files in cross-platform packages or being careful with naming), but they don't because it's not an issue that would ever occur to them, unlike case-insensitivity.
>>>
>>> Many systems are case-insensitive
>> Really? Aside from Windows what other systems are case insensitive?
> The default HFS+ on OS X is the big one for unixy developers (but there's also OS/2 HPFS, ISO9660, most of the Amiga filesystems, VMS and I think RT-11 :) ).
Such popular and current systems! Amiga? Seriously?
>>>   It's a niche environment, and not used by many developers who target a unix-style environment, so most developers packaging software will not be aware of the issue and won't work around it.
>> I don't think I've met many developers who target a Unix-style environment who did not know about Cygwin and, if forced to use Windows, use Cygwin. Granted the foo vs. foo.exe thing is a bit obscure, but I'd say that a Unix developer actually naming something .exe is also pretty rare.
> For a pure unix developer, sure. For a cross-platform developer maybe less so.
The fix is simple, probably less keystrokes than your last two 
responses... Oh, excuse me. You were not seeking a solution. Never mind 
then...
>>> Treating "foo" and "foo.exe" as equivalent is a very non-unixy thing to do
>> Neither is naming some thing with a .exe at the end!
> Sure it is. I can use any string I like to name a file! :)
You can - but why would you? Generally people don't tack on a .exe 
unless they are trying to say something. What are they trying to say?
> (And I have seen it done with some CAD apps in the dim and distant past where the actual executable was /opt/foo/bin/bar.exe which was called from a wrapper script shell /opt/foo/bin/bar. Slightly odd, sure, but not entirely silly.)
By "slightly odd" and "dim and distant past" I'd say it's not all that 
frequent nor much of a problem by definition. Why then do you appear to 
fight for it so? It's beyond me. But good luck!
>>> ("everything is a file, and the name of the file isn't important to the kernel") so it's particularly surprising behaviour on a system that otherwise looks quite like a unix environment.
>>>
>>> (I'd assumed that cygwin worked by intercepting execve(), and it hadn't even occurred to me that it would modify filesystem access at a coarser level than that until I started diagnosing apparent bugs in tar).
>>>
>>> It's not a serious problem, of course - but it does mean that the most widely used cross-platform GUI library cannot be unpacked on cygwin and built from source without jumping through hoops. Given that the cygwin environment is very attractive to cross-platform developers I'm betting I'm not the first person who has been burned by this, and won't be the last.
>> So why don't you ask them to fix it?
> Because it's not their bug, and it's something that'll pop up elsewhere too. (Note that I'm not asking anyone working on cygwin to fix it either, just reporting the issue, asking if my understanding of the bug is correct and current, then sticking around for the conversation.)
Hmmm... OK, so if you don't want them to fix it, nor want Cygwin to fix 
it, I'll assume the conversation is pretty much over at this point.
>> I mean what do they need a foo and a  foo.exe for anyway?
> configure is a shell script that does what configure always does. configure.exe is a windows binary that does much the same thing for a windows platform.
So when untarring in Cygwin, which one wins? If configure the shell 
script then my guess is we don't have a problem. So it must be that the 
Windows .exe is overwritting the shell script. Hmmm... What's a old 
bearded, pure Unix guy from Amiga/VMS land doing packing a Windows .exe 
into a tar! He oughta be tarred! And feathered! ;-)
-- 
Andrew DeFaria <http://defaria.com>
Always remember you're unique, just like everyone else.


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