On 07/11/2018 13:13, Jaikiran Pai wrote:
:
My impression, based on that javadoc, was that the implementation of
that API will use the underlying _filesystem_ to decide whether or not
its case sensitive. However, my experiments on a macOS which is case
insensitive and also a basic check of the implementation code in the
JDK, shows that this uses a lexicographic check on the string
representation of the paths. Is that what this javadoc means by
"underlying system". I understand that there's a further sentence in
that javadoc which says UNIX systems are case significant and Windows
isn't. However, it wasn't fully clear to me that this API wouldn't
delegate it to the underlying filesystem on the OS.
Maybe the javadoc could be clearer but having an equals method delegate
to the underlying file system would be very problematic (think URL
equals or cases where the file path is relative or doesn't locate a file).
While we are at it, is there a better API that can be used to do such a
case sensitivity check of the underlying filesystem? I checked the APIs
in java.nio.file but couldn't find anything relevant. If there isn't any
such API currently, is that something that can be introduced?
This has been looked into a couple of times over the years, suggestions
have included FileStore exposing a comparator that uses the rules of a
specific underlying file system or volume. This turns out to be very
complicated as it means looking beyond case sensitively issues and into
topics such as case preservation, Unicode normalization forms, per
volume case mapping tables, and handling of limits and truncation.
-Alan
