Patch to allow trailing dots on managed mounts

Pierre A. Humblet pierre@phumblet.no-ip.org
Fri Dec 17 17:17:00 GMT 2004



Christopher Faylor wrote:
> 
> On Thu, Dec 16, 2004 at 10:43:47PM -0500, Pierre A. Humblet wrote:
> >
> >The key point in my patch is that it's the output Win32 path
> >that must be checked, not the input path.
> 
> How can that be?  As I mentioned previously, if you don't perform the
> fixups prior to inspecting the mount table then "ls /bin.........."
> won't work.

Huh?
In a normal Cygwin install, /bin... uses the mount point for / and is
translated to c:\cygwin\bin... 
Windows maps this to c:\cygwin\bin, and we can fix the output path
in :check() so that NtCreateFile does the same.

Note in passing that "ls /bin..." "works" in a rather strange way:
CYGWIN_NT-4.0 usched40576 1.5.12(0.116/4/2) 2004-11-10 08:34 i686
<snip>
ls: /bin.../znew: No such file or directory
This has always been the behavior.

Continuing on your example, ls /usr/bin... only "works" (as above)
since the 2004/04 changes. Before that date, one could mount
c:\cygwin\bin -> /usr/bin
c:\something -> /usr/bin...
and ls /usr/bin... would list c:\something
If you try that today, ls /usr/bin... lists c:\cygwin\bin, but 
ls /usr/bin.../somefile lists c:\something\somefile !!!
I think we should revert to the old behavior, i.e. try to be as
Posix like as possible.

Before 2004/04 one could also have an executable "abc...exe" and typing
"abc.." would invoke it. Again I think we should revert to that behavior
Yesterday I gave a similar example with symbolic links.
They show that the input tail isn't always the same as the output tail.
Windows only cares about the output tail, and so should Cygwin
(but only when Windows does). 

Pierre



More information about the Cygwin-patches mailing list