-
Notifications
You must be signed in to change notification settings - Fork 171
8186464: ZipFile cannot read some InfoZip ZIP64 zip files #452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
👋 Welcome back andrew! A progress list of the required criteria for merging this PR into |
|
This backport pull request has now been updated with issue from the original commit. |
|
/contributor add Thomas Fitzsimmons fitzsim@redhat.com |
|
@gnu-andrew |
|
❗ This change is not yet ready to be integrated. |
I'm confused. The original patch https://hg.openjdk.org/jdk10/master/rev/723486922bfe touches ZipFile.java, not zip_util.c. How is this a clean apply? AFAICS this patch re-implements part of the original patch. |
|
@gnu-andrew @fitzsim I concur with @tstuefe: What are the changes in |
|
Sorry for the delay in replying; I did not notice that @tstuefe had commented. Thanks for reviewing @jerboaa and @tstuefe . I did the zip_util.c change to fix this Windows build failure (from my notes, because I cannot find the run in GitHub Actions anymore): The older compiler on that build machine needed the end64buf declaration to be at the start of the function. I do see end64buf is declared in the same place in zip_util.c on jdk master, so it would make more sense to start there and backport that change separately. But now I wonder why no one else has seen this and fixed it already. I think my next step should be to change this pull request to remove the zip_util.c part and see if the builders pass. If they do, then this review can proceed. If they don't, then I will file a jdk/master bug with the relevant explanation and pointers to GHA logs. |
|
(From what I can tell, I will not receive GitHub email updates just for comments on this pull request because I did not file it -- that is why I did not receive a notification for @tstuefe's initial question. I will try to visit this/refresh this more often, and @jerboaa's mention of me did send a notification. See also https://github.com/orgs/community/discussions/44376) |
|
@fitzsim Yes, please remove the |
|
I will also investigate whether the |
|
@jerboaa Yes, @gnu-andrew explained it in the first comment of this pull request:
|
|
Basically, @gnu-andrew is the author, but I volunteered to do the submission process, and we are not sure how to represent that situation with the tooling. |
I'm afraid, there is not much we can do but for @gnu-andrew to drive this (because of SKARA-2173). The only alternative is to erase some of the credit, which is probably not wanted. |
|
I did more research: the C parts of the proposed changes are jdk8u-specific, so there are no equivalent parts of zip_util.c in newer branches from which to backport them. They are there because they avoid the need to backport the entire large JDK9-era rewrite of the Java parts of Zip support to jdk8u. |
Do you know which bug did the rewrite? It would be good to have that on record. |
|
Here is some public discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1433262#c21 and https://bugzilla.redhat.com/show_bug.cgi?id=1433262#c22 |
If you remove the The test and zipfs changes are the same. The reason I didn't upstream this at the time of development was I was unsure that the test was adequately testing the changes, particularly the ZipFileSystem ones. In 9+, the ZipFileSystem is part of the JDK, thanks to JDK-8038500: "(zipfs) Upgrade ZIP provider to be a supported provider" and so I presume is tested by the Thomas kindly agreed to verify the tests and upstream the patch. I think the 'clean patch' confusion arose from the RPM patch applying cleanly, not the 11u version. |
|
@gnu-andrew This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
I am experimenting to figure out which parts of |
|
@gnu-andrew This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
I am working on test cases for https://bugs.openjdk.org/browse/JDK-8334048. I found some good ones in the original commit, "8186464: ZipFile cannot read some InfoZip ZIP64 zip files", but it turns out they have since been reworked, so I have to follow the history of them to figure out the best way to adapt the logic now. Assuming the test cases I provide satisfy the reviewers, I can backport 8334048 separately from this one, which will become just about the demo Java Zip implementation in 8. |
|
openjdk/jdk#19678 is ready for review if someone who looked at this one wants to take a look at the |
|
@gnu-andrew This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
@gnu-andrew This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
This is a re-do of #445 as we reached a deadlock where I could not make myself commit author, as I was not the PR author, and Thomas could not make me the author as he was not a Committer (see SKARA-2173). The content remains the same.
What follows is Thomas' introduction from the original PR:
This patch was applied to the Red Hat 1.8.0 RPMs in June 2020, so it has been deployed to Red Hat customers for over three years.
I verified that the patch applies cleanly to jdk8u-dev master. I confirmed that with the fix portion of the patch reverted, the ReadZip.java test portion of the patch produces this exception:
With the fix applied the test passes:
With the patch applied on top of jdk8u-dev master tip, 3dc011b,
make teston Fedora 38 x86-64 passes, with:I also retested the test cases in JDK-8186464 and confirmed that without this backport, they fail, and with the backport they succeed.
Thank you,
Thomas
Progress
Issue
Contributors
<fitzsim@redhat.com>Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/452/head:pull/452$ git checkout pull/452Update a local copy of the PR:
$ git checkout pull/452$ git pull https://git.openjdk.org/jdk8u-dev.git pull/452/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 452View PR using the GUI difftool:
$ git pr show -t 452Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/452.diff
Webrev
Link to Webrev Comment