On Mon, 12 May 2025 15:57:35 GMT, Alan Bateman <[email protected]> wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment based on current behaviour.
>
> src/jdk.zipfs/share/classes/module-info.java line 160:
>
>> 158: * will always be opened <em>read-write</em> (see {@code
>> "accessMode"}
>> 159: * below), regardless of whether the underlying ZIP already
>> existed or
>> 160: * not.
>
> In the default provider, "read-only && create" ignores the create option so
> the open fails if the file does not exist.
>
> For the zipfs provider then doing the same, or having this combination be an
> error, is okay. I think it might be a bit too surprising to have "read-only
> && create" create a read-write file system.
Is this comment just agreeing with the proposed behaviour stated here?
At the moment the code prohibits "read-only && create". It's an illegal
argument exception (see tests).
The only allowed access mode options with "create" are "readWrite" or
<no-option>, and in both cases you get back a ZipFileSystem for which
"isReadOnly()" is false. We'd already agreed that any explicit access mode
needs to always be honoured.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085381219
