readdir() returns inaccessible name if file was created with invalid UTF-8
Corinna Vinschen
corinna-cygwin@cygwin.com
Fri Jun 27 14:59:51 GMT 2025
On Jun 27 15:32, Christian Franke via Cygwin wrote:
> $ touch $'t-\xef\x80\x80'
> The name mapping is:
> "t-\xEF\x80\x80" -(open, ...)-> L"t-\xDB59" -(readdir)-> "t-"
Did you copy/paste this from the old mail, by any chance?
Using the latest test DLL the mapping is
"t-\xEF\x80\x80" -(open, ...)-> L"t-\xF000"
And that's basically correct, albeit it leads to problems.
You know that we defined the area from 0xf000 to 0xf0ff as our private
use area to create filenames with characters invalid in DOS filenames
by transposing these chars into the private use area. When converting
the filenames back, the 0xf0XX chars are transposed back to 0xXX.
But yeah, I found the bug here. The problem is that the transpose table
incorrectly contains NUL as transposable character. So if you create
L"t-\xF000", that's fine. However, when converting this name back to
UTF-8, the filename becomes L"t-\0". Oops.
I dropped the ASCII NUL from the list of transposable characters and
now what you get is this:
$ touch $'t-\xef\x80\x80'
$ touch $'t-\xef\x80\x81'
$ ls -l
total 0
-rw-r--r-- 1 corinna vinschen 0 Jun 27 16:49 't-'$'\001'
-rw-r--r-- 1 corinna vinschen 0 Jun 27 16:49 't-'$'\357\200\200'
Apart from the incorrect transposition of ASCII NUL, the transposition
works transparently:
$ echo foo > $'t-\xef\x80\x81'
$ cat $'t-\xef\x80\x81'
foo
$ cat $'t-\x01'
foo
I'll apply the patch shortly.
Thanks,
Corinna
More information about the Cygwin
mailing list