Corinna Vinschen wrote: >> 22 12422 [main] ls 1300 fhandler_disk_file::readdir_helper: wchar >> filename: "Mikey12\xf020.ai" > > That's the problem. The character in that file is *not* U+0323, but > U+f020, a character in the Unicode private use range, which is used in > Cygwin to map ASCII characters invalid in Windows filenames but valid > in POSIX filenames. It's also used to map multibyte characters > 0x80 > which are invalid in the current charset.
Thanks for diagnosing my problem. My assumption that the char was U+0323 was based on scrolling through the Windows Character Map app for something that visually matched what I was seeing in the filename. Not having any other way to quantify the char, I jumped to an incorrect conclusion. This also explains why my test on another machine produced the correct result. Instead of actually copying the troublesome file over to that machine, I lazily created a filename there containing the char (U+0323) I presumed to be causing trouble on the first machine. I have since verified that the char U+0323 works fine in filenames on all my Cygwin 1.7 boxes, while the char U+f020 fails on all of them. > You must not use characters > in this range from U+f000 up to U+f0ff. There's no solution to this > except for "don't use these characters in filenames if they are not > explicitely written there by either Cygwin or Microsoft's SUA". The above two sentences should probably go into the UG. > See > http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-specialchars That section of the UG only says that certain special chars are mapped by Cygwin into the 0xf000 to 0xf0ff range. It does not explicitly say that Cygwin may not be able to deal with filenames containing arbitrary chars from that range, hence my suggestion that the UG be updated. Thanks again, -SM -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
