On Mon, 12 May 2025 20:19:43 GMT, David Beaumont <d...@openjdk.org> wrote:
>> 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.
I agree that read-only && create is a combination to be rejected. My comment
is about the update to the description of the "create" option. It's the first
row in the table and the changes suggests that it is forcing the file system to
be read-write. I think the wording for the "readOnly" option is sufficient,
meaning just one place to document the conflict between these two options.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2085993836
