Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs
jai.forums2013 at gmail.com
Mon Dec 11 15:46:06 UTC 2017
Moved this thread from discussions mailing list to here. Comments inline.
On 11/12/17 7:55 PM, Alan Bateman wrote:
> On 11/12/2017 14:06, Jaikiran Pai wrote:
>> So a few related questions that I have are:
>> 1. Is this inconsistency an expected behaviour or is this a bug?
>> 2. If this is an expected behaviour, then would it be a better
>> idea (as an application developer) to use Path.toRealPath instead
>> of using the File.getCanonicalPath()? Are these 2 APIs semantically
>> equivalent? The File.getCanonicalPath() talks about the canonical
>> path being "unique" paths but the Path.toRealPath has no such mentions.
> The correctness issues with the canonicalization cache is a long
> standing issue . You can workaround it by running with
> -Dsun.io.useCanonCaches=false as I think you have found. The goal is
> to eventually disable and remove it. The first steps to get there
> happened in JDK 9 when FilePermission was changed to not canonicalize
> by default (FilePermission was the original motivation for this cache).
> If you have follow-up questions then please bring the thread to
>  https://bugs.openjdk.java.net/browse/JDK-7066948
Thanks Alan. Given that the cache itself is being planned to be
eventually removed, that answers the main part of my question and I can
workaround this issue in a couple of ways (disabling the cache using
that system property is one way) in the application, till that time.
The only remaining part that I'm curious about is this:
> ... would it be a better idea (as an application developer) to use
Path.toRealPath instead of using the File.getCanonicalPath()? Are
these 2 APIs semantically equivalent? The File.getCanonicalPath() talks
about the canonical path being "unique" paths but the Path.toRealPath
has no such mentions.
More information about the core-libs-dev