Christian Franke via Cygwin wrote:
Thomas Wolff via Cygwin wrote:
Am 15.09.2024 um 20:15 schrieb Thomas Wolff via Cygwin:
Am 15.09.2024 um 19:47 schrieb Christian Franke via Cygwin:
If a file name contains an invalid (truncated) UTF-8 sequence, open()
does not refuse to create the file. Later readdir() returns a
different name which could not be used to access the file.
Testcase with U+1F321 (Thermometer):
$ uname -r
3.5.4-1.x86_64
$ printf $'\U0001F321' | od -A none -t x1
f0 9f 8c a1
$ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext'
$ touch 'file2-'$'\xf0\x9f\x8c''.ext'
$ touch 'file3-'$'\xf0\x9f\x8c'
$ ls -1
ls: cannot access 'file2-.?ext': No such file or directory
ls: cannot access 'file3-': No such file or directory
'file1-'$'\360\237\214\241''.ext'
file2-.?ext
file3-
I don't reproduce this.
Yes, sorry, the above 'ls' was actually aliased to 'ls --color=auto'
which needs to call stat(). Plain 'ls' does not, so the errors do not
occur then.
While the file name gets mangled, all resulting file names are valid
and
listed:
In file2 the sequence is turned into U+17B3 but exchanged with the dot.
In file3 the same sequence is just dropped.
$ ls -1|cat
file1-🌡.ext
file2-.ឳext
file3-
However, ls file2* fails, as does ls *.
On the other hand, ls file3- fails too, so some mapping error occurs
internally.
Also, the files cannot be deleted from cygwin (need to use cmd).
'rm' using the original names works for file2-..., but not for file3-...
$ rm -v 'file2-'$'\xf0\x9f\x8c''.ext'
removed 'file2-'$'\360\237\214''.ext'
$ rm -v 'file3-'$'\xf0\x9f\x8c'
rm: cannot remove 'file3-'$'\360\237\214': No such file or directory
Further tests suggest that the problem only occurs with:
- incomplete 4 byte UTF-8 sequences (Unicode above 16 bit)
- complete but invalid 3 byte UTF-8 sequences which encode the UTF-16
'high surrogate' range (0xD800..0xDBFF).
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
