Cygwin managed mounts give surprising (to me) results if a filename that's not in its canonical form manages to get below the managed mountpoint:
$ mkdir managed unmanaged $ mount -o managed `cygpath -aw managed` $PWD/managed $ mkdir unmanaged/dir $ touch unmanaged/dir/Foo $ mv unmanaged/dir managed $ ls -l managed/dir ls: cannot access managed/dir/Foo: No such file or directory total 0 ?????????? ? ? ? ? ? Foo This is because path.cc's fnunmunge() leaves the Win32 filename "Foo" alone when it returns the directory entry for readdir(), but the corresponding fnmunge() transformation for stat() turns "Foo" into "%46oo", which doesn't exist in the directory. This problem appears to be known on the Internet, but was very puzzling to me until I figured out what was happening. Is there any reason why fnunmunge() shouldn't case-smash all non-quoted alphabetic characters in Win32 filenames to lower case? I.e., in this case, report the name of the file in managed/dir as "foo"? I believe this would ensure that the round-trip Win32->managed POSIX->Win32 file name transformation would always result in a valid Win32 name for the file. (I haven't been able to construct any other Win32 filenames that don't map to a valid managed-POSIX filename.) Is there a downside to this, other than an extra call to cyg_tolower in fnunmunge? -- Jonathan Lennox lennox at cs dot columbia dot edu -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
