coreutils-5.3.0-3

[Thomas Wolff]

I have rechecked some inconsistencies with the magic ".exe" suffix 
handling (see http://sourceware.org/bugzilla/show_bug.cgi?id=581) 
with coreutils 5.3.0 and here is an updated summary of inconsistencies 
and unexpected behavior (some issues resolved, some new ones appeared):


me@host:~> ls x*
x.exe
me@host:~> cat > x
bash: x: cannot overwrite existing file
--> should have created "x" which does not exist


me@host:~> ls x*
x.exe
me@host:~> ln x y
--> OK
me@host:~> mv x y
/bin/mv: cannot remove `x': No such file or directory
--> misleading message
me@host:~> mv -i x.exe y.exe
--> should have prompted


> ls y*
y.exe
> mv y.exe y
/bin/mv: `y.exe' and `y' are the same file
--> should have renamed


me@host:~> ls x* y*
x.exe  y
me@host:~> cp -i x y
/bin/cp: overwrite `y'? y
/bin/cp: cannot create regular file `y.exe': No such file or directory
--> confusing message; should have created "y"


me@host:~> ls x*
x.exe
me@host:~> rm -i x
/bin/rm: remove regular file `x'? y
/bin/rm: cannot remove `x': No such file or directory
--> handling inconsistent; first, it maps, then no more


me@host:~> ls x*
x.exe
me@host:~> ls -i x
3659174697246106 x
-->              ^ this is actually "x.exe"
me@host:~> touch x
me@host:~> ls -i x
1970324836996817 x
-->              ^ now it's "x", a different file
--> mapping inconsistent; maybe it should rather look like:
me@host:~> ls x*
x.exe
me@host:~> ls x
x.exe
--> this is my proposal


Kind regards,
Thomas Wolff