-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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. 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), and to make people with bad scripts
write more robust code. The autotools are already rather good at using
${EXEEXT} where needed in makefiles and elsewhere.
>>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.
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.
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?
>
> 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.
foo. is a non-portable filename, but cygwin does provide managed mounts
where it is a valid filename, so I agree with you that using foo. as the
means to say `remove this file exactly' is not a good idea.
>
> Regards,
> Ralf
>
According to Christopher Faylor on 4/12/2005 11:07 PM:
>>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.
>
>
> You implied that "this isn't even coreutils fault".
>
> If it isn't coreutils fault, that would imply that cygwin was doing
> something wrong and that coreutils is working around something in
> cygwin.
>
> I don't see what that is. If we stripped out all exe handling you would
> still apparently put it back into coreutils. The fact that stat() finds
> .exe files and unlink() doesn't seems rather irrelevant to me, since
> you've more or less produced a wrapper around unlink() but not stat(),
> because stat() didn't need one.
>
> The bottom line is that whatever cygwin did or didn't do, the user would
> end up seeing the same behavior.
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. 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.
One last note - cygwin unlink() still has the POSIX bug I reported earlier
where calling unlink() on a file in a directory with no write permissions
still removes the file, thanks to the underlying Windows implementation.
Worse, because the directory has no write permissions, you can't directly
re-create a new file to replace the one that was erroneously deleted. But
Chris already argued that checking for write permissions on the parent
directory as part of every unlink() call would slow down the common case.
I could work around this in coreutils rm by providing an unlink() wrapper.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-----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
iD8DBQFCXR1/84KuGfSFAYARAjmqAKDL3jvycAfi2Eco+Z958+mho/DpvgCeJlW8
+KB4EuS9LBoEiNLvFkhqtyI=
=XySH
-----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/
