> The ZipFileSystem check is case sensitive:
>
Ah, that's not obvious at all... and even if this is an undocumented option
I'd add a comment in the test
or remove it to Map.of() for clarity. That bug entry in Jira doesn't have
"affects" pointing at older releases - I think it should since it affec
Hi Dawid
Thank you for getting back to me.
> On Nov 29, 2020, at 5:00 PM, Dawid Weiss wrote:
>
>
> Hi Lance,
>
> I looked at the test you pointed to... This is exactly the test for the
> problem I originally reported on October 21st... The bug has been filed
> for this on October 25th (by yo
Hi Lance,
I looked at the test you pointed to... This is exactly the test for the
problem I originally reported on October 21st... The bug has been filed
for this on October 25th (by you) --
https://bugs.openjdk.java.net/browse/JDK-8255380 and the fix is in commit
6606e0909cbda9. Weird.
I think t
Hi Dawid,
Thank you for the follow up.
> On Nov 28, 2020, at 9:34 AM, Dawid Weiss wrote:
>
>
> I know what the problem is and I know what the fix should be (and tried to
> convey it) but I don't have a patch.
Given you believe you know what the fix would be, it would be great to create
a p
I know what the problem is and I know what the fix should be (and tried to
convey it) but I don't have a patch. Writing the test case is not a problem
but it'll be a lengthy test on slower drives (has to create a zip file that
exceeds 4gb of disk space). I don't think there is a way to fake the fil
Hi Dawid,
If you believe you have a a fix, please submit a patch along with a JTREG test
case. Ideally the test case would create zip file as part of the test.
Best
Lance
> On Nov 27, 2020, at 7:37 AM, Dawid Weiss wrote:
>
> Just for the archives - I'm not sure if this ended up being filed t
Just for the archives - I'm not sure if this ended up being filed to
the bug system - the repro below demonstrates the bug on all JDKs up
to the newest one.
# create a single random file of 250 megabytes
head -c 250M < /dev/urandom > rnd.bin
# create a bunch of hardlinks to the same file.
for i in
This looks like a legitimate bug to me (the zip file system implementation
is sensitive to the order of extra parameters and may throw an unexpected
error
on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no
permissions - but I think it'd be worth adding one?
Dawid
On Wed, Oct
Hi Lance,
Yes, this is exactly the point where the problem is in JDK code. It's directly
related to the zip entry beyond max int offset. The code tries to read data
from a local zip entry header at locoff, here:
if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
but the locoff is set to ~0 as pe
Hi David,
From a quick look at ZipFileSystem this appears to be an optimization to avoid
looking at the LOC extended Timestamp Extra field
If a Info-ZIP Extended Timestamp (0x5455)is found then:
If the "zipinfo-time" entry was set to “false” in the Map specified when
creating the Zip FileSy
Hello,
We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
entries are intact) that causes a runtime exception when scanning its
contents with ZipFileSystem. The exception indicates an invalid
signature when parsing EXTID_EXTT. I don't quite understand this
comment in the code:
11 matches
Mail list logo
