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.
