Filesystem case sensitive check and

Roger Riggs Roger.Riggs at
Wed Nov 7 15:07:19 UTC 2018

Hi Jaikiran,

To check if two pathnames are the same file, 
java.nio.file.Files.isSameFile(path1, path2)
is cleaner.  It uses the file system specific mechanisms to determine if 
the two paths
refer to the identical file.  Traversing symbolic links, etc.

Something like:
             Path dir = ...;   // supply a directory to test a 
particular file system
             Path path1 = Files.createTempFile(dir, "MixedCase", "");
             Path path2 = Path.of(path1.toString().toLowerCase(Locale.US));
             return Files.isSameFile(path1, path2);

or similar...


On 11/07/2018 09:27 AM, Jaikiran Pai wrote:
> Hi Alan,
> On 07/11/18 7:15 PM, Alan Bateman wrote:
>> 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).
> I see what you mean. About the javadoc, do you think it is worth
> improving and if so, should I file an enhancement at
>>> 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.
> So I guess, that leaves us (the client applications) to rely on some
> kind of file creation tricks like the one below to figure this out:
>          // create a temp file in a fresh directory
>          final Path tmpDir = Files.createTempDirectory(null);
>          final Path tmpFile = Files.createTempFile(tmpDir, null, null);
>          tmpFile.toFile().deleteOnExit();
>          tmpDir.toFile().deleteOnExit();
>          // now check if a file with that same name but different case is
> considered to exist
>          final boolean existsAsLowerCase =
> Files.exists(Paths.get(tmpDir.toString(),
> tmpFile.getFileName().toString().toLowerCase()));
>          final boolean existsAsUpperCase =
> Files.exists(Paths.get(tmpDir.toString(),
> tmpFile.getFileName().toString().toUpperCase()));
>          // if the temp file that we created is found to not exist in a
> particular "case", then
>          // the filesystem is case sensitive
>          final boolean filesystemCaseSensitive = existsAsLowerCase ==
> false || existsAsUpperCase == false;
> One final question - is there anywhere in the JDK code, where files are
> auto created (for whatever purpose)? If such a construct exists, maybe
> during the initialization of each FileStore implementation, it could do
> such tricks (maybe in a much better and performant way) and figure out
> this detail and then expose it some way? It feels hacky to do it in the
> JDK, so I fully understand if such a construct won't be entertained.
> -Jaikiran

More information about the core-libs-dev mailing list