RFR: 8173970: jar tool should have a way to extract to a directory
Jaikiran Pai
jai.forums2013 at gmail.com
Thu Mar 4 02:40:40 UTC 2021
Hello Lance,
On 03/03/21 9:14 pm, Lance Andersen wrote:
>
>
> Some other things needed to be defined and agreed upon in order to
> move forward
>
> * The behavior if the path does not exist
> * If the option is specified more than once on the command line
> * Clarify the behavior if any of the files exist in the specified
> target directory.
>
One of my previous reply included the details of how I think it should
behave for 2 of the above cases. I'll paste that here again for easier
visibility. As for how it should behave if the option is specified more
than once, I'll spend some time today to see how the jar tool currently
behaves for some of the other options in this aspect and send back my
response. Thank you for your help so far. Pasting below my proposal from
a previous reply for the other 2 cases:
>
> There are other discussion points around the behavior when the target
> directory exists or does not exist, to ensure there is some
> consistency with main stream tools.
I'm guessing you mean the behaviour of creating a directory (or a
hierarchy of directories) if the target directory is not present? My
testing with the tar tool (both on MacOS and CentOS) shows that if the
specified target directory doesn't exist, then the extract fails. The
tar extract command doesn't create the target directory during extract.
On the other hand, the unzip tool, does create the directory if it
doesn't exist. However, interestingly, the unzip tool creates only one
level of that directory if it doesn't exist. Specifically, if you specify:
unzip foo.zip -d /tmp/blah/
and if "blah/" isn't a directory inside /tmp/ directory, then it creates
the "blah/" directory inside /tmp/ and then extracts the contents of the
zip into it.
However,
unzip foo.zip -d /tmp/blah/hello/
and if "blah/" isn't a directory inside /tmp/ directory, then this
command fails with an error and it doesn't create the hierarchy of the
target directories.
Coming to the jimage and the jmod commands, both these commands create
the entire directory hierarchy if the target directory specified during
extract, using --dir, doesn't exist. So a command like:
jimage extract --dir /tmp/blah/foo/bar/ jdkmodules
will create the blah/foo/bar/ directory hierarchy if blah doesn't exist
in /tmp/, while extracting the "jdkmodules" image.
From the user point of view, I think this behaviour of creating the
directories if the target directory doesn't exist, is probably the most
intuitive and useful and if we did decide to use this approach for this
new option for jar extract command, then it would align with what we
already do in jimage and jmod commands.
One another minor detail, while we are at this, is that, IMO we should
let the jar extract command to continue to behave the way it currently
does when it comes to overwriting existing files. If the jar being
extracted contains a file by the same name, in the target directory
(hierarchy) then it should continue to overwrite that file. In other
words, I don't think we should change the way the jar extract command
currently behaves where it overwrites existing files when extracting.
-Jaikiran
More information about the core-libs-dev
mailing list