https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-15768 Lustre <p>AFAIK, we don't test UTF-8 or UTF-16 support for a variety of reasons (mostly because the file system itself should support it without issue). That said, given the wide range of possible file names these days, including file names with emojies it should be tested to ensure that this does in fact work as expected.</p> <p>Another thing to note here is that the existing tests may blow up with these character sets and may need some adjustments like LANG=C.UTF-8 to ensure the environment is ready for UTF-8 support.</p> <p>Thoughts?</p> LU-15768

Add tests for UTF-8 and UTF-16 handling.

Improvement Minor Open Unresolved WC Triage Colin Faber Wed, 20 Apr 2022 15:25:27 +0000 Thu, 21 Apr 2022 17:37:51 +0000 0 2 <p>Linux system calls do not support paths encoded as UTF-16 strings. When the string <tt>"foo/bar"</tt> is encoded in UTF-16 every other byte will be NUL (0). To the Linux kernel and to Lustre, a path is a NUL terminated sequence of bytes.</p> <p>I would be surprised if a well written application would attempt to use a UTF-16 encoded string as a path on Linux.</p> <p>There are no UTF-16 locales.</p> <p>UTF-8 encoded string with Emojis or whatever work just fine as pathnames. They also work just fine with the kind of string handling done in a command like lfs.</p> <p>One issue that may arise is with something like Python which is very strict about encoding correctness. To make up for the strictness, Python includes a path container type (see <a href="https://docs.python.org/3/library/pathlib.html" class="external-link" target="_blank" rel="nofollow noopener">https://docs.python.org/3/library/pathlib.html</a>).</p> Development Rank 1|i02njr: Rank (Obsolete) 9223372036854775807