On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bjørsnøs wrote:
>> Sounds like a CSR is needed for the behavioral change proposed here.
>
>> Sounds like a CSR is needed for the behavioral change proposed here.
>
> Thanks for flagging this @jddarcy
>
> I'm personally not 100% convinced a CSR is
On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bjørsnøs wrote:
> > Sounds like a CSR is needed for the behavioral change proposed here.
>
> Thanks for flagging this @jddarcy
>
> I'm personally not 100% convinced a CSR is warranted in this case, but I'm of
> course happy to extend the following into
On Mon, 8 Jan 2024 18:21:06 GMT, Joe Darcy wrote:
> Sounds like a CSR is needed for the behavioral change proposed here.
Thanks for flagging this @jddarcy
I'm personally not 100% convinced a CSR is warranted in this case, but I'm of
course happy to extend the following into a CSR if you or
On Mon, 8 Jan 2024 15:43:34 GMT, Jaikiran Pai wrote:
> The crucial part here is that the "current" `ZipEntry` is the one which was
> created by a previous call to `ZipInputStream.getNextEntry()` method, which
> is a public overridable method. Furthermore, the `ZipEntry.getExtra()` method
>
On Mon, 8 Jan 2024 15:04:58 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into data-descriptor
>> - Extract ZIP64_BLOCK_SIZE_OFFSET as a
On Mon, 8 Jan 2024 14:59:40 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into data-descriptor
>> - Extract ZIP64_BLOCK_SIZE_OFFSET as a
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Mon, 8 Jan 2024 14:47:48 GMT, Jaikiran Pai wrote:
> With the current proposed change, we not only rely on the Inflater for this
> decision but also rely on ZipEntry itself to tell us whether to read 8 bytes
> or 4 bytes each.
The proposed change resides solely in one single
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Fri, 22 Dec 2023 07:55:24 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte
14 matches
Mail list logo
