Re: Patch to allow trailing dots on managed mounts

["Pierre A. Humblet" <pierre at phumblet dot no-ip dot org>]

At 09:44 PM 12/18/2004 -0500, Christopher Faylor wrote:
>
>For now, I'm disallowing all use of '.\' and ' \' in a path.  It seems
>more consistent to disallow everything than to allow some stuff.  I
>didn't change the symlink code to disallow "ln -s foo bar..."  If someone
>actually complains about this, maybe I will.
>
>So, "ls /bin........." works, "ls /bin./pwd.exe" doesn't work and "ls
>/cygwin/c/cygwin/bin./pwd.exe" doesn't work either.  Nor does
>"ls c:\cygwin\bin.\pwd.exe".  I don't know if we'll hear complaints about
>this one or not.

Excellent decisions. 
Although ls would work with 'bin./', NtCreateFile couldn't open the
file and things requiring a handle (like the inode) would be 
reported incorrectly.

Do you intent to remove the dot checking code in normalize_xxx_path?
It now seems to be useless and even counterproductive.
 
>>Also, for my info, what is the unc\ in
>>       !strncasematch (this->path + 4, "unc\\", 4)))
>>around line 868? I have never seen that documented.
>
>I've always wondered about that myself.  I am pretty sure it predates
>me.  I've removed that test.  It doesn't make any sense to me either.

Thanks. I made some progress on that one, looking at 
path_conv::get_nt_native_path.

\\.\unc\computer\share indicates a remote share. So apparently the intention
was to add a final \ in that case, but not on \\.\c: (according to the
comment) nor on \\.\c:\somedir   (why not??), and never with PC_FULL.
Is there ever any reason to add a \ to a Windows path?
 
Now, I checked (on XP Home) that "dir \\.\c:" does NOT work, while "dir \\.\c:\"
does work, which seems to contradict the intention in the comment.
Also "ls //./c:" does not work, but neither does "ls //./c:/", because Cygwin
strips the final '/' and it's needed for GetFileAttributes (fails with WinError 87).
path_conv will probably never be completely right!  

Pierre