This is the mail archive of the
mailing list for the Cygwin project.
Re: Patch to allow trailing dots on managed mounts
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
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.