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

[Ralf Wildenhues]

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