tar won't extract all files when a file with exe extension precedes the same without extension inside the archive

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Fri Jul 13 17:26:00 GMT 2012

On Fri, Jul 13, 2012 at 09:20:11AM -0700, Andy Hall wrote:
>>>2.  Since this is a "Windows thing", is there some reason why the
>>>execution of "file" or "file.exe" isn't handled as a special case in
>>>the exec call (and all its flavors) and no place else?
>>make, for example?  If you have a rule that creates "foo" from foo.c,
>>gcc will actually create "foo.exe".  The next time you run make, it
>>won't see "foo" and recreate "foo.exe", even if "foo.exe" is still up
>>to date.
>>With the special handling of .exe, when make checks for "foo", cygwin
>>checks "foo" first, doesn't find anything, and then checks "foo.exe",
>>returning its result to make and make is happy.
>>Anothen example: A script tries to execute "foo" from .  , cygwin
>>executes "foo.exe" instead and the script thinks "foo" exists, but a
>>subsequent "touch foo" (or "rm foo" or whatever) fails, which is
>>massively inconsistent.
>>I consider the current handling of .exe files quite consistent.
>>Or, in other words, when forced to choose between the two pains, I'd
>>rather endure this.
>Well, this seems to be something that has to be addressed specifically
>in make and gcc (and other similar places).  If make has a rule to
>create "foo" from foo.c, then that is what it should do! Dennis Ritchie
>would turn over in his grave is he heard that commands like tar, rsync,
>zip, ...  were not idempotent WRT at least filenames and contents, let
>alone permissions.

I didn't know Dennis Ritchie but I'll bet that, if we were still alive,
he would actually be intelligent enough and pragmatic enough to listen
to rationales for a behavior and, if the problem really interested him
enough, he'd undoubtedly do more than just whine.  He'd offer solutions.

I think this subject has been run into the ground.  Although I'll grant
you that positing the in-grave behavior of Dennis Ritchie is new, it
isn't helpful, and there is nothing else in this tedious discussion
which has offered any useful new insight, let alone actual code changes.
Heaven forbid that someone would actually look at the Cygwin code and
make informed comments.

So, everyone, please let this drop unless you have a constructive

This is your mailing list administrator speaking.

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

More information about the Cygwin mailing list