Christopher Faylor wrote: > While I detest the trailing dot crap, I don't want cygwin to be inconsistent. > I don't want ls /bin./ls.exe to fail but ls /cygdrive/c/bin./ls.exe to work.
Assuming a normal install, the first one is c:\cygwin\bin.\ls.exe, which would NOT fail, while the second is c:\bin.\ls.exe, which would fail as expected (not due to dots). You probably mean /usr/bin./ls.exe (fail) vs. /cygdrive/c/cygwin/bin./ls.exe (no fail, although NtCreateFile fails and Cygwin backs off to alternate code). Cygwin has always behaved that way (still does), without generating complaints about inconsistencies. We can't fix Windows, but I don't see why we should add processing to disallow behavior that it allows, or mimic its crazy behavior when we don't have to. > I'm not sure that it makes sense for ln -s foo "bar." to actually create a > file > with a trailing dot on a non-managed mount either. That seems to expose an > implementation detail of the way links are handled and it seems inconsistent > to me. Perhaps, but nobody has complained about it over the years! Look at it positively: Cygwin can implement symbolic link names in a Posix way, without tail dot/space limitations. Ditto with /proc/registry. Actually if one is porting some code that has a hardcoded filename ending with a dot, it's nice to have a simple way (symbolic link to valid Windows name) of making it work. > If we are "fixing" this (I firmly believe that the code in path_conv is never > really going to be right) then I don't want to add inconsistencies. I agree that path_conv is never going to be "right". I would not reduce functionality nor open new holes merely to reduce inconsistencies due to Windows. Would it be better to eliminate the inconsistency by allowing ls /usr/bin./ls.exe (and how many dots? spaces?) or by disallowing ls /cygdrive/c/cygwin/bin./ls.exe (and ls c:/cygwin/bin./ls.exe) ? I can argue either way, with a preference for disallowing (to avoid accidental aliasing, although it breaks precedent, and because on NT, "touch /cygdrive/c/cygwin/bin./ls.exe" fails naturally). Overall I would leave the inconsistency as it is, and blame it on Windows and on Cygwin tradition. There are repeated complaints about /usr/bin/somefile not having the same binary/text mode as /cygdrive/c/cygwin/bin/somefile or c:\cygwin\bin\somefile. We rightly dismiss them, although that can be seen as an inconsistency, and it's purely a Cygwin issue. Pierre
