Am 19.03.2012 20:16, schrieb Jeffrey Altman:
2. Finder does display Unicode Strings in composed form but always sends
strings back to the file system in decomposed form which results in the
file names not being found.
We've got the same problem with German umlauts, and yes, this seems to
be what's happening. Opening files with an umlaut in the name results in
an error message, whereas directories with umlaut are simply displayed
as empty, without any message, which is particularly confusing for
unsuspecting users. (This is with OpenAFS 1.6.1 on Mac OS X 10.7.4.)
The UNIX AFS clients do not perform UTF8 string detection and do not
normalize strings for comparison as is performed on Windows. In
addition, on Windows, the Explorer Shell always reflects file names back
to the file system in the encoding presented by the file system. In my
opinion this is what OS X should do but doesn't.
A radar should be opened with Apple.
Did anyone log this issue with Apple? If so, what's the URL?
However, even if Apple were to change this behavior, it would only fix
one half of the problem, namely, allowing applications on Mac OS X to
access files created on Linux/Windows.
The other way around, though, there are problems too. As a simple test
I've created a file named "täst.txt" on Mac OS X. Now, in a terminal
window on Linux, the file name is displayed properly, but I can't access
the file by typing its name. Using tab completion works, but not if the
part before the first umlaut is ambiguous.
On Windows XP, the file name is displayed incorrectly, in that the dots
above the a are shifted to the right by half a character (which sort of
makes sense, given that the combining diaeresis character is stored
after the a; but it's incorrect nevertheless). When opening the file
with notepad, the window title shows it as "ta▫st.txt" (i.e. instead of
the diaeresis, there's a small square between a and s).
In summary, while it is at least possible to access umlaut-y files from
Mac OS X on other platforms, it is rather kludgy. Furthermore, it
strikes me as inelegant to have files with different normalizations
within one filesystem, and given that there are applications which are
very picky about filenames (such as Tivoli Storage Manager), I'm
concerned this might become rather messy.
Therefore, I'm in favor of normalizing file names to precomposed form in
the Mac version of the AFS client, since it would fix both halves of the
problem, and we wouldn't have to wait for Apple to change the behavior
of Mac OS X (if they are going to do so at all).
Sebastian Flothow
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info