RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions

[Francisco Ferrari Bihurriet]

On Fri, 17 Oct 2025 10:07:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman are you ok with letting the original [c6f1d5f](https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab) reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else?
>> 
>> Have you had time to try using the file key to detect the recursive include case?
>
>> Hi @AlanBateman, I'm resuming the work on this one.
>> 
>> > Have you had time to try using the file key to detect the recursive include case?
>> 
>> By "file key", do you mean `Files.readAttributes(Path.of("..."), BasicFileAttributes.class).fileKey()`? This works on _Linux_ but returns `null` on _Windows_.
> 
> Can you try Files.isSameFile? It will use the file key on all platforms. If the file located by the included path, and the previous files encountered, are accessible then it can be loadFromPath..

@AlanBateman: I will try it, but please let me insist on the fact that the circular include detection is a secondary problem here (it's solved for any of the alternatives and the current mainline code). However, we still need a reliable way to determine the base directory for relative includes.

@seanjmullan: that would be more or less the franferrax at fbec2fd80a9930cf4cb00f4f35684f2e2cc2fbf1 alternative from [this comment](https://github.com/openjdk/jdk/pull/24465#issuecomment-3114241142) (instead of using `FileInputStream`, just avoid `java.nio.file.Path::toRealPath`, not only if there isn't any `include`, but also for all the `include` statements that are absolute). Please also refer to the table in the comment, as that alternative doesn't solve the 7abb62c069ad35f4ec34f6cd9b9f6d05febceecc variant.

This PR has been opened for 205 days now, and I've put a considerable effort:

* Debugging and documenting the underlying OS APIs ([here](https://github.com/openjdk/jdk/pull/24465#issue-2973770332) and [here](https://github.com/openjdk/jdk/pull/24465#issuecomment-2803609222))
* Thinking and testing possible problematic scenarios ([here](https://github.com/openjdk/jdk/pull/24465#issuecomment-2835992962))
* Analyzing and developing a test for a variant of the original issue (7abb62c069ad35f4ec34f6cd9b9f6d05febceecc)
* Providing and testing several alternatives ([here](https://github.com/openjdk/jdk/pull/24465#issuecomment-3114241142))

I understand there is more rush now because we found more customers affected by it, but that doesn't change my position, I'm still convinced that the currently proposed fix is the best option among the analyzed alternatives (or perhaps franferrax at c9a3985c7d11335f3c9b8ab67d166bdc2a16289f, if we prefer to be conservative at the cost of a slightly less simple code).

I don't believe it should take longer to come up with a fix.

[JDK-8352728]: https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3453483597