cygwin coreutils-5.3.0-4 rm change breaks Libtool

[Eric Blake]

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

Rather, my question is two-fold:
1. Should more syscalls should do .exe magic?  It is sometimes confusing
when *stat() and access() say a file exists, but open(), rename(),
unlink(), and others fail with ENOENT on the same spelling.  Since many of
the coreutils first perform a stat, they end up making invalid assumptions
that the file exists, and when later syscalls return ENOENT it leads to
confusing error messages.  The current cygwin-specific patch to things
like rm(1) is that following a successful stat(), open() is performed (on
ENOENT, .exe is needed; on success or other errors such as EPERM, .exe is
not needed).  But a successful open() followed by an immediate close(),
just so the program can later invoke the normal syscall it was designed
for, is expensive.

2. Should *stat() and access() be given a POSIX-compatible extension that
programs "in the know" can use to bypass a more expensive syscall to
determine whether the current filename spelling of an existing file is
correct?

For access: in <unistd.h>, #define _CYGWIN_NO_IMPLICIT_EXTENSION 8 (or
some nicer name still in the implementation namespace), then access("foo",
F_OK) can return success whether "foo" or "foo.exe" exists, but
access("foo", _CYGWIN_NO_IMPLICIT_EXTENSION | F_OK) can only return
success if "foo" exists.  Perhaps even add an easily identifiable errno
EEXTNEEDED that means that the file doesn't exist, but adding an extension
would work (since cygwin has already added the non-standard ECASECLASH),
and only set errno to EEXTNEEDED if _CYGWIN_NO_IMPLICIT_EXTENSION was passed.

For *stat: <cygwin/stat.h> already has some spare fields (8 bytes) in
struct __stat64.  Carve out 3, 4 or 5 of those bytes (depending on whether
room for a leading dot or trailing NUL is deemed important) to treat them
as the char[] extension that must be added to the filename passed to
stat() for that filename to succeed in other syscalls.  This can even
cover case sensitivity issues - always appending ".exe" might not work
correctly if the user named it ".Exe", but stat could return the exact
case on disk.  Then, when stat("foo", &st) succeeds, the user can inspect
st.st_ext to see what extension, if any, was used to get the Windows file
handle used populate the other fields of st.

> 
> If you wanted to just make people always have to specify .exe then you
> probably should have just introduced a simple wrapper around stat which
> defeated cygwin's attempt to detect .exe's.

No, I think there are too many shell usability issues and inconsistencies
with other programs if coreutils refused to do .exe magic.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCXIlM84KuGfSFAYARAtIWAJ48xpHqW9yz9QOl7KJgVLsNtYHGbACfWOQF
GSmEVqYSZtdQebuWjjWUTfo=
=GzTP
-----END PGP SIGNATURE-----


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