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

[Francisco Ferrari Bihurriet]

On Fri, 7 Nov 2025 16:27:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Detect cyclic includes with Files::isSameFile
>>   
>>   checkCyclicInclude() is invoked after we successfully get an InputStream
>>   for the path to avoid skipping the same IOException several times inside
>>   checkCyclicInclude() if the path doesn't exist.
>>   
>>   Also, perform symlinks resolution only in the following cases:
>>    • When we need to resolve a relative include
>>    • For clarity to the user in logging messages
>>    • For clarity to the user in exception messages
>>   
>>   In the first case, the resolution is a requirement, in the last two
>>   cases it is a nice-to-have. But given the last two are exceptional
>>   cases anyway, we let any resolution error bubble up.
>
> src/java.base/share/classes/java/security/Security.java line 288:
> 
>> 286:                                 "Cyclic include of '" + resolve(path) + "'");
>> 287:                     }
>> 288:                 } catch (IOException ignore) {}
> 
> Not sure you want to ignore this - seems better to let this propagate and be thrown as an `InternalError`.

We can make this an `InternalError`, the most common failure case is one of the two files nonexistence. So before proceeding I want to make sure you are aware that this would make the following filesystem race-condition noticeable:

1. File **A** is included, _OpenJDK_ starts reading it
2. File **A** is deleted by and administrator who is changing the settings
    * But _OpenJDK_ keeps it open, this is possible in _Linux_
3. File **B** is included, _OpenJDK_ wants to check for a circular inclusion
4. `Files.isSameFile(path, activePath)` throws `IOException` when `path` is file **B** and `activePath` is file **A** (now deleted)
5. `IOException` isn't ignored but wrapped in an `InternalError` and thrown

Current code wouldn't fail in this scenario, although I recognize it's a corner case. I decided to ignore the exception under the assumption that `Files.isSameFile(x, y)` can be treated as `false` in this context for cases in which either `x` or `y` is nonexistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2519491637