Bug 581 - Confusing error message with ".exe" aliasing
Summary: Confusing error message with ".exe" aliasing
Status: RESOLVED FIXED
Alias: None
Product: cygwin
Classification: Unclassified
Component: Cygwin Applications (show other bugs)
Version: unspecified
: P3 minor
Target Milestone: ---
Assignee: Christopher Faylor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-26 11:39 UTC by Thomas Wolff
Modified: 2010-08-20 18:16 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wolff 2004-11-26 11:39:32 UTC
Cygwin has some built-in intelligence to suppress ".exe" and enable 
virtual non .exe filenames, e.g.
ls x works and shows x even if actually only x.exe exists.

If this (mis?)leads me to enter a command like "cp x y", 
I get a confusing error message
/bin/cp: `x' and `y' are the same file
Comment 1 Christopher Faylor 2004-11-26 15:25:10 UTC
This is not a DLL problem.  The DLL is working as designed.
Comment 2 Thomas Wolff 2004-12-22 10:51:55 UTC
Component changed to "Cygwin support utilities".

With the new coreutils, the confusing error message is actually gone.
But a number of subtle inconsistencies remain in handling implicit 
.exe suffixes. I quote them "in line":

-- good with cp, inconsistent with ln and mv:
me@host:~> ls x* 
x.exe
me@host:~> ls x
x
me@host:~> ls -i1 x x.exe 
3659174697246106 x
3659174697246106 x.exe
me@host:~> ln x y
ln: creating hard link `y' to `x': No such file or directory
me@host:~> mv x y
/bin/mv: cannot move `x' to `y': No such file or directory
me@host:~> cp x y
me@host:~> ls y*
y.exe
me@host:~> 

-- good with cp:
me@host:~> ls x* y*
x.exe  y.exe
me@host:~> cp -i x y
/bin/cp: overwrite `y'? y
me@host:~> ls x* y*
x.exe  y.exe
me@host:~> 

-- not good with cp:
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
me@host:~> 

-- not good with rm:
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
me@host:~> 

-- confusing with ls:
me@host:~> ls -i x
3659174697246106 x
me@host:~> #     ^ this is actually x.exe
me@host:~> touch x
me@host:~> ls -i x
1970324836996817 x
me@host:~> #     ^ now it's x, a different file
me@host:~> 

-- maybe it should rather look like:
me@host:~> ls x
x.exe
me@host:~> 
Comment 3 Thomas Wolff 2005-03-09 14:58:20 UTC
Rechecking with coreutils 5.3.0 gives the following 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 "x"


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
Comment 4 Christopher G. Faylor 2010-08-20 18:16:34 UTC
ancient