On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <d...@openjdk.org> wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a little refactoring to ensure that "read only" state was set
>> initially and only unset at the end of initialization if appropriate.
>>
>> By making 2 methods return values (rather than silently set non-final fields
>> as a side effect) it's now clear in what order fields are initialized and
>> which are final (sadly there are still non-final fields, but only a split of
>> this class into two types can fix that, since determining multi-jar support
>> requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fixed test.
test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 224:
> 222: // Underlying file is read-only.
> 223: Path readOnlyZip = Utils.createJarFile("read_only.zip",
> Map.of("file.txt", "Hello World"));
> 224: readOnlyZip.toFile().setReadOnly();
`java.io.File.setReadOnly()` specifies:
> On some platforms it may be possible to start the
> Java virtual machine with special privileges that allow it to modify
> files that are marked read-only. Whether or not a read-only file or
> directory may be deleted depends upon the underlying system.
So I think we should run the subsequent asserts in this test after first
checking if the file was set to read-only. If it isn't then we should skip the
test. Something like:
final boolean marked = readOnlyZip.toFile().setReadOnly();
Assumptions.assumeTrue(marked, "skipping test since " + readOnlyZip + "
couldn't be marked read-only");
assertThrows(IOException.class,
() -> FileSystems.newFileSystem(readOnlyZip,
Map.of("accessMode", "readWrite")));
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095650541
