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