<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="monospace">Hello Lance,</font><br>
</p>
<div class="moz-cite-prefix">On 03/03/21 9:14 pm, Lance Andersen
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<div class=""><br class="">
</div>
<div class="">Some other things needed to be defined and agreed
upon in order to move forward</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">The behavior if the path does not exist</li>
<li class="">If the option is specified more than once on the
command line</li>
<li class="">Clarify the behavior if any of the files exist in
the specified target directory.</li>
</ul>
</div>
</blockquote>
<p>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:<br>
</p>
<p><br>
</p>
<blockquote type="cite" style="font-size: large; color: #007cff;">
<br>
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.
<br>
</blockquote>
<br>
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:
<br>
<br>
unzip foo.zip -d <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>tmp/blah<span
class="moz-txt-tag">/</span></i>
<br>
<br>
and if "blah/" isn't a directory inside <i class="moz-txt-slash"><span
class="moz-txt-tag">/</span>tmp<span class="moz-txt-tag">/</span></i>
directory, then it creates the "blah/" directory inside <i
class="moz-txt-slash"><span class="moz-txt-tag">/</span>tmp<span
class="moz-txt-tag">/</span></i> and then extracts the contents
of the zip into it.
<br>
<br>
However,
<br>
<br>
unzip foo.zip -d <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>tmp/blah/hello<span
class="moz-txt-tag">/</span></i>
<br>
<br>
and if "blah/" isn't a directory inside <i class="moz-txt-slash"><span
class="moz-txt-tag">/</span>tmp<span class="moz-txt-tag">/</span></i>
directory, then this command fails with an error and it doesn't
create the hierarchy of the target directories.
<br>
<br>
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:
<br>
<br>
jimage extract --dir <i class="moz-txt-slash"><span
class="moz-txt-tag">/</span>tmp/blah/foo/bar<span
class="moz-txt-tag">/</span></i> jdkmodules
<br>
<br>
will create the blah/foo/bar/ directory hierarchy if blah doesn't
exist in <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>tmp<span
class="moz-txt-tag">/</span></i>, while extracting the
"jdkmodules" image.
<br>
<br>
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.
<br>
<br>
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.
<p>-Jaikiran<br>
</p>
</body>
</html>