JDK 1.8.0_66, diacritics and file problems, follow up

[Alan Bateman]

On 12/05/2016 13:11, Fabrizio Giudici wrote:
> :
>
> The Paths submitted to the test are discovered by Files.walk().
>
> What I'm seeing is that all the troubled files show now no access 
> problems with NIO, while IO fails (e.g. toFile().exists() returns 
> false while Files.exists(path) returns true).
>
> :
>
>
> The following code thus can be used to probe a troubled Path (so far I 
> see that the problem only happens with the EXT4 filesytem; no problems 
> with e.g. BTRFS and HFS+):
>
>     private static boolean isTroubled (final @Nonnull Path path)
>       {
>         return Files.exists(path) != path.toFile().exists();
>       }
>
> I was able to implement a first workaround for libraries I'm using 
> that unfortunately are based on java.io.File: I create a temporary 
> symbolic link without diacritics, use it in place of the original, 
> then delete it after the processing, and it works.
I assume is a decoding and encoding round trip issue, meaning bytes -> 
String -> bytes. When you use the new file system API then you are using 
a Path which will use the underlying representation to access the file. 
Once you call toString or switch to java.io.File the bytes are decoded, 
and then re-encoded when you access the file via File::exists. Yes, all 
very subtle.

So you can summarize the environment? You mention HFS+ and there is a 
mention about use NFD normalization. There is also a mention of a 
Raspberry Pi. So are the files transferred between the systems or is 
there SAMBA or other network access in the picture.

-Alan.