MacOS file system changes between 7u10 and 7u40?
Philippe Marschall
philippe.marschall at gmail.com
Mon Sep 23 00:28:22 UTC 2013
On Sun, Sep 22, 2013 at 4:31 PM, Michael Hall <mik3hall at gmail.com> wrote:
> On Sep 22, 2013, at 4:17 PM, Philippe Marschall wrote:
>
> On Sat, Sep 21, 2013 at 6:23 AM, Michael Hall <mik3hall at gmail.com> wrote:
>
> On Sep 21, 2013, at 2:41 AM, Philippe Marschall wrote:
>
>
> I'll have to change the in-memory implementation and
>
> tests to match the new MacOS behavior.
>
>
>
> Meaning match the new openjdk default filesystem path encoding, matching the
>
> Java 6 path encoding.
>
>
> I haven't checked what the "old" java.io.File API on Java 6 does.
>
>
> I thought Alan said something about matching Java 6 and 'old' java.io.File
> was and is all that is provided there.
> At least you don't have to emulate MacRoman it sounds like.
>
>
> There is no actual MacOS itself behavior change.
>
> Correct?
>
>
> Yes MacOS behaves still the same (NFD). However the Java default file
> system implementation of the new file system API on MacOS now returns
> NFC instead of NFD.
>
>
> Not sure what the distinction is there, I should check.
This is mainly about Latin-1 backwards compatibility in Unicode. Some
(most) Latin-1 characters that are not in ASCII can be represented in
two ways in Unicode.
NFD as one code point: eg. ä
NFC as two code points one of them being a combinatorial diacritical
mark: eg. ¨a
MacOS AFAIK stores file names in NFD.
> Emulating a platform filesystem is an interesting idea.
It's targeted at testing file code without actually going to disk.
Much like testing database code with an in-memory database.
Cheers
Philippe
More information about the nio-dev
mailing list