This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool


On Tue, Apr 12, 2005 at 08:52:22PM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to Christopher Faylor on 4/12/2005 5:44 PM:
>>On Tue, Apr 12, 2005 at 10:51:20PM +0000, Eric Blake wrote:
>>
>>>To some degree, the problem isn't even coreutils fault - cygwin itself
>>>is where it was decided that stat(2) succeeds for either "foo" or
>>>"foo.exe" when only "foo.exe" exists, but that unlink(2) fails unless
>>>it is spelled "foo.exe".  The implicit .exe magic I added in rm is
>>>simply recognizing that if stat succeeded but unlink failed, that
>>>unlink should be tried a second time with the correct extension.
>>
>>I'm not sure I understand this.
>>
>>If cygwin were made to not treat .exe specially, that would mean that,
>>presumably, either you'd remove all of your patches from coreutils and
>>make people use .exe specifically, or you would work around the lack of
>>.exe by adding it on your own.
>
>Don't get me wrong - I was not asking to have cygwin's .exe magic
>removed.  I like having .exe automagically appended.  It is much more
>unix-like to be able to refer to a compiled file without an extension,
>even though the underlying Windows needs the extension for exec*() to
>succeed.

You implied that "this isn't even coreutils fault".

If it isn't coreutils fault, that would imply that cygwin was doing
something wrong and that coreutils is working around something in
cygwin.

I don't see what that is.  If we stripped out all exe handling you would
still apparently put it back into coreutils.  The fact that stat() finds
.exe files and unlink() doesn't seems rather irrelevant to me, since
you've more or less produced a wrapper around unlink() but not stat(),
because stat() didn't need one.

The bottom line is that whatever cygwin did or didn't do, the user would
end up seeing the same behavior.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]