MacOS file system changes between 7u10 and 7u40?
Martin Buchholz
martinrb at google.com
Fri Oct 4 08:30:40 PDT 2013
It is already the case that you cannot access all possible Unix file names
from Java because by design, file names are represented by Java strings
(UTF-16), but at the OS level filenames are actually arbitrary byte
sequences with no concept of encoding.
On Fri, Oct 4, 2013 at 4:32 AM, Philippe Marschall <
philippe.marschall at gmail.com> wrote:
> On Fri, Sep 27, 2013 at 6:44 AM, Xueming Shen <xueming.shen at oracle.com>
> wrote:
> > What we did in 7130915 is to normalize the native macos file name (in
> NFD)
> > back into
> > NFC for the File and Path, but passing the File/Path Java path name (in
> NFC)
> > into macos's
> > file system API directly (as it appears those APIs just work fine with
> NFC
> > file name, though
> > it stores them in NFD internally). This serves the purpose of having Java
> > file name
> > (File and Path, and their String representation) in NFC form
> consistently,
> > cross all platforms.
>
> This is not the behavior I'm seeing on Linux and Windows. They don't
> seem to do any normalization at all (I read that Windows does NFC but
> my tests seem to contradict this) and in addition you can have NFC and
> NFD file names side by side. That means you can't have normalized
> Paths in NFC on those platform at all times because then certain files
> would not be accessible to Java.
>
> I could not check ZFS which seems to be normalization-insensitive /
> normalization-preserving [1]. This would open the option to normalize.
>
> > As the consequence, we can have a reasonable implement of file name
> > equals() without
> > involving string normalization, which is expensive. In "normal" use
> > scenario, you should
> > not have a file/path name (in String) passing around in NFD form.
>
> [1]
> https://blogs.oracle.com/nico/entry/normalization_insensitivity_should_be_the
>
> Cheers
> Philippe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131004/b7edee0f/attachment.html
More information about the nio-dev
mailing list