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

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Wed, Apr 13, 2005 at 03:24:15PM CEST:
> According to Ralf Wildenhues on 4/13/2005 1:17 AM:
> > 
> > Hmm.  Here you talk about the superficial symmetry in mv/cp vs rm..
> 
> Only rm was given new .exe magic.  cygwin mv and cp have had them for
> several years, before coreutils was even bundled as part of cygwin.

Oh, I'm mostly fine with these having the magic.

To be more precise: Since stat(2) does not appear in atomicity questions
at all (whatever answer stat gives you, the moment you have it it may be
wrong), it's much less of an issue than unlink(2).

Speaking of command line tools, you have ways to work around stat,
namely readdir, but not really for rm.

> I'm afraid that changing the other way, and stripping all .exe magic
> out of coreutils, may break other things on cygwin.  But maybe it is
> worth the change, to force better POSIX compliance (command line tools
> aren't changing filenames behind your back),

I don't use cygwin much, so my opinion is not very well founded here.
First, with mv/cp the problems are not so bad(?), second you might break
things now by changing, as you already said.

> >  .. 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.
> 
> Well, there are several cygwin syscalls that are not atomic, even though
> POSIX requires them to be (just recently, there was a thread about
> symlink() not being usable in cygwin as a locking mechanism:
> http://sourceware.org/ml/cygwin/2005-03/msg01024.html).  I can remove all
> .exe magic from cygwin, but there are other programs that also have .exe
> magic.  For example, in the shell, invoking `test -x foo' returns success
> and `./foo' runs foo.exe when only foo.exe exists; then again, I think
> this shell magic is attributable to cygwin's stat() and exec*() magic, and
> not to a patch in bash itself.

Sure.  FWIW, it would be nice to have some overview on what POSIX
behavior doesn't work on cygwin (the short list of differences, not the
common ground as in cygwin-api.html).  I haven't searched very long,
though.

> As a side note, when POSIX requires atomicity of a syscall and cygwin
> can't provide it with respect to Windows, would it at least be possible to
> provide atomicity with respect to other cygwin programs via an
> interprocess mutex managed by cygwin1.dll?  Or is this so slow that
> providing the atomicity would noticibly degrade performance in the common
> case?

Probably the latter.

> Based on the comments of Ralf, Chris, and others, maybe the best approach
> for me to take is the following (but I'd like comments from others
> agreeing to this change before I spend time implementing it):
> 
> Instead of writing wrappers around all the syscalls that don't do implicit
> magic, I would instead write a wrapper around stat that undoes cygwin's
> underlying .exe magic.

I would doubt about the usefulness of such an approach.  If you don't
get cygwin to do what you want (whatever that may be in the end),
working around it might just make matters worse.  I also don't think you
can workaround without introducing more race conditions.

> Then I could add cygwin-specific command line
> options to the various tools where .exe magic has been useful (cp, mv,
> stat, ...).  That way, when invoked as POSIX requires, the command line
> spelling has to match the directory contents, but with the extra option
> the .exe magic appears.  The user can make an alias or function that
> implicitly adds the cygwin option if they like .exe magic, but libtool
> would no longer be forced to work around it.

Not so sure it makes things easier overall.  In many (user) cases,
adding .exe automatically helps, and leads to basically the same
behavior as on POSIX systems: you compile foo, you execute foo, but
underlying is foo.exe.  With your new approach, the user needs this
extra option.

But then again, take my opinion with a grain of salt, please, as I have
little experience with cygwin.

Regards,
Ralf