Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <425C8966.3000802@byu.net> Date: Tue, 12 Apr 2005 20:52:22 -0600 From: Eric Blake User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool References: <041220052251 DOT 26916 DOT 425C50E800071C000000692422007507840A050E040D0C079D0A AT comcast DOT net> <20050412234432 DOT GA17857 AT trixie DOT casa DOT cgf DOT cx> In-Reply-To: <20050412234432.GA17857@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes -----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 , #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: 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 AT byu DOT 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/