-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8345506: jar --validate may lead to java.nio.file.FileAlreadyExistsException #22734
Conversation
👋 Welcome back jpai! A progress list of the required criteria for merging this PR into |
@jaikiran This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 41 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/label remove compiler |
@jaikiran |
Webrevs
|
@@ -431,8 +431,9 @@ public synchronized boolean run(String[] args) { | |||
file = new File(fname); | |||
} else { | |||
file = createTemporaryFile("tmpJar", ".jar"); | |||
try (InputStream in = new FileInputStream(FileDescriptor.in)) { | |||
Files.copy(in, file.toPath()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you try adding the REPLACE_EXISTING option to Files.copy, I assume that will fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello Alan, I had thought about that, but then I looked at the implementation of Files.copy(...)
with REPLACE_EXISTING
. If that option is specified, the Files.copy(...)
implementation first deletes the existing file:
// attempt to delete an existing file
if (replaceExisting) {
deleteIfExists(target);
}
before it initiates the copying. It didn't feel right to be explicitly creating a file (before the call to Files.copy) and then having it deleted due to the use of REPLACE_EXISTING
. So I went ahead with this alternate approach.
Would you still prefer that we use REPLACE_EXISTING
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you Lance for the review. Alan, is it OK to proceed with this current change or do you think we should pursue the REPLACE_EXISTING
option here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't object to what you have, it's the mixing of old and new APIs that jumped out. Maybe some day there will be some wider updates to the jar tool in this area, e.g. it could have use a temp directory rather than a temp file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for that input, Alan. I'll go ahead with integrating this current PR. As a separate activity, I will take a broader look at this jar tool code and see what changes can be accomodated to modernize the code.
/integrate |
Going to push as commit 725079b.
Your commit was automatically rebased without conflicts. |
Can I please get a review of this change which proposes to address the issue reported in https://bugs.openjdk.org/browse/JDK-8345506?
The
jar
tool has several operations which take--file
as a parameter. The value for that option is a JAR file path. Thejar
operation is then run against that JAR file. The--file
parameter is optional and when it isn't provided, thejar
tool expects the JAR file content to be streamed through STDIN of thejar
process.The issue here is that the
--validate
option has a bug in the implementation where when the--file
option is absent, it tries to read from the STDIN into a temporary file that the implementation just created. To do so it usesFiles.copy(...)
which throws an exception if the destination file exists (which it does in this case because that temporary destination file was created just a few lines above).The fix in this commit address this issue by using an alternate way to transfer the JAR content into the temporary file.
A new jtreg test has been introduced to reproduce the issue and verify the fix. I couldn't locate any other existing test which was exercising the code path which deals with
jar
operations against the STDIN of thejar
process. So the new jtreg test has test for other operations and not just--validate
operation.The new test and existing tests in tier1, tier2 and tier3 continue to pass with this change.
Progress
Warning
8345506: jar --validate may lead to java.nio.file.FileAlreadyExistsException
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22734/head:pull/22734
$ git checkout pull/22734
Update a local copy of the PR:
$ git checkout pull/22734
$ git pull https://git.openjdk.org/jdk.git pull/22734/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22734
View PR using the GUI difftool:
$ git pr show -t 22734
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22734.diff
Using Webrev
Link to Webrev Comment