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
