Surprising results (ls: no such file or directory) with managed mounts

[Jonathan Lennox <lennox at cs dot columbia dot edu>]

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/