tar deletes .exe files on extraction (again)
Fri Sep 23 20:03:00 GMT 2011
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
>>> contains. The "configure.exe" that's required to build Qt is never
>>> from the tarball.
>>> The problem is that the cygwin filesystem shims consider "configure"
>>> "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
>>> 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
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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...
> *** 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin