On Fri, Dec 17, 2004 at 07:36:15PM -0500, Christopher Faylor wrote:
If /cygdrive/c/cygwin/bin./ls.exe works, then /bin./ls.exe should also work.
Or, both should fail. "consistent"
Thinking some more about this, there are really some inconsistencies with
the current and proposed behavior that I don't like.
Here's a table. Please let me know if I got anything wrong:
What Now Pierre's proposal Windows Equiv
ls /bin... Works Won't work dir c:\cygwin\bin... doesn't work
ls /bin. Works Won't work(?) dir c:\cygwin\bin. works
ls /lib/gcc. Works Works(?) dir c:\cygwin\lib\gcc. works
ls /lib./gcc. Works Won't work(?) dir c:\cygwin\lib.\gcc. works
ls /cygdrive/c/cygwin/bin. Works Works(?) dir c:\cygwin\bin. works
ls /bin../ls.exe Won't work Won't work dir c:\cygwin\bin..\ls.exe won't work
Won't work Won't work ditto
ls /bin/ls.exe... Works Works(?) dir c:\cygwin\bin\ls.exe... works
ln -s foo bar. "Works"* Works** .lnk files with dot extensions allowed
If I understand this correctly, I think "Pierre's proposal" == "cygwin's
behavior before 2004/4", on all counts.
So, in thinking about all of this, I have a radical proposal which I
have previously alluded to.
path_conv::check could detect the existence of trailing dots or spaces
in path components of the output win32 path and set ENOENT in such cases
unless the file was associated with either a managed mount or Corinna's
proposed "posix" mount.
The rationale for this is that you really can't (except in the symlink
case) create a file with a trailing dot so why should we lie and say
that you can?
This probably is too radical an idea and would result in breakage. So,
my alternate thought is that single dots should be silently ignored in
all path components. Multiple dots should be ignored in the trailing
path component, regardless of whether the file refers to a directory or
not, which makes cygwin slightly incompatible with windows.
I'm not sure how spaces fall out in the above table. I'm not sure that the
same rules should be applied for spaces and dots above.