Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: endor.wiss-staff: wildenhu set sender to Ralf DOT Wildenhues AT gmx DOT de using -f
Date: Wed, 13 Apr 2005 09:17:03 +0200
From: Ralf Wildenhues <Ralf DOT Wildenhues AT gmx DOT de>
To: Eric Blake <ericblake AT comcast DOT net>
Cc: Robert =?iso-8859-1?Q?=D6gren?= <lists AT roboros DOT com>, cygwin AT cygwin DOT com,
   bug-libtool AT gnu DOT org
Subject: Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool
Message-ID: <20050413071703.GA22055@iam.uni-bonn.de>
Mail-Followup-To: Eric Blake <ericblake AT comcast DOT net>, Robert =?iso-8859-1?Q?=D6gren?= <lists AT roboros DOT com>, cygwin AT cygwin DOT com, bug-libtool AT gnu DOT org
References: <041220052251 DOT 26916 DOT 425C50E800071C000000692422007507840A050E040D0C079D0A AT comcast DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <041220052251.26916.425C50E800071C000000692422007507840A050E040D0C079D0A@comcast.net>
User-Agent: Mutt/1.4.1i
Organization: Department of Numerical Simulation, University of Bonn

Hi Eric, others,

* Eric Blake wrote on Wed, Apr 13, 2005 at 12:51:20AM CEST:
> [cc'ing bug-libtool]

Thanks for doing this.  Note that we were planning to get another 1.5.x
point release out this or next weekend.  Might be nice to have a fix in
there.

Some food for thought:

> > the change in rm semantics, implicit .exe handling, in coreutils-5.3.0-4 
> > breaks Libtool (1.5.10, and some later versions). More specifically, 
> > when Libtool is used to link an executable which requires a wrapper 
> > script to handle uninstalled libraries, the corresponding wrapper .exe 
> > is now incorrectly removed (but not the script without the .exe 
> > extension).

> When I added implicit .exe handling to rm in the latest cygwin
> release, I did not realize that any program would be depending on the
> previous semantics.  It would be nicer if we could keep the .exe
> handling in rm, to keep symmetry with the handling done in mv, cp,
> install, etc.

Hmm.  Here you talk about the superficial symmetry in mv/cp vs rm..

> Is there anything else in cygwin besides libtool
> depending on the old semantics, where in a directory with foo.exe but
> not foo, `ls foo' succeeds but `rm foo' fails?  If other cases are
> found, then I will probably have to release a coreutils-5.3.0-5 for
> cygwin that removes the implicit .exe behavior for rm (or a patch that
> adds a cygwin-specific flag that can suppress the .exe handling at
> will), but I'd rather see libtool patched if it is the only program
> affected.
> 
> 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.

 .. while here you we see that the underlying difference is: stat vs
unlink.  Besides the fact that I am not too happy with any of the ".exe
magic": I wonder whether anyone relies on `rm -f' being atomic.

*snip*
> Is there any way to patch libtool to check whether the script exists
> before trying to remove it?  One possible approach that works with
> current cygwin, whether using coreutils 5.3.0 cygwin patchlevel 3 (`rm
> foo' fails) or 4 (`rm foo' removes foo.exe if no foo exists):

It looks like one could adjust Libtool to your change.  But I'd really
advise you to think about this issue again, and about the possibility of
other code (silently) relying on the old behavior as well.

> Shell globbing relies on readdir(2), which, unlike stat, does not lie
> about file extensions.  So, libtool could use shell globbing to
> determine the correct spelling of the existing filename to decide
> whether rm should be applied.  The problem spot is already local to
> cygwin, but it would be nice to have it in the upstream libtool
> sources.

Erm, does this mean there is no way to explicitly specify "I want to
remove this file exactly"?

BTW, on non-cygwin, I would not want to forbid users to use `foo.' as a
valid file name.

Regards,
Ralf

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