2018/2/11 23:10:46 -0800, Michal Vala <mv...@redhat.com>:
> On 02/10/2018 11:25 AM, Alan Bateman wrote:
>> I think the `jimage extract --dir <existing-file> <jimage-file>` scenario
>> discussion. If <existing-file> is a non-directory file then jimage has to
>> I don't expect disagreement on that. For the case where it is an existing
>> directory then the options seem to be:
>> 1. Extract into the existing directory (existing JDK 9 and JDK 10 behavior)
>> 2. Fail if it's not empty (your patch)
>> 3. Fail if it exists (Mandy's mail, the motivation being to keep it
>> with jlink)
>> I view `jimage extract --dir <dir>` as being similar to `unzip -d <dir>` so
>> don't think existing behavior (#1) is incorrect, the only issue is that it
>> silently overrides files whereas unzip will prompt before overriding (unless
>> specify -o). The `jar` tool, and legacy `tar` tool side with `jimage` and
>> happy to silently replace existing files.
>> What would you think about focusing on the override case instead of
>> extracting into an existing non-empty directory? I realize this is more work
>> it means deciding on whether to prompt, warn or fail. It also means thinking
>> about the equivalent of unzip -o to allowing existing files be replaced.
> Unzip prompts user for individual files and I'm not sure whether it's a good
> option here. Maybe prompt user at the beginning that directory is not empty
> there is a risk that files there might be overwritten continue y/n?
CLI tools that prompt the user are difficult to use in scripts,
so I advise against that.
jimage is a diagnostic tool meant for rare and specialized use.
I think its current behavior (extract into an existing directory)
is fine, and I can imagine use cases where that might actually be