Skip to content

Decompress: default to Renaming over Overwriting when solving conflicts #966

@marcospb19

Description

@marcospb19

(This is a follow-up to the new archive decompression behavior introduced in #962.)

When ouch decompress archive.tar is called, and neither are --here (equivalent to --dir .) or --dir OTHER_FOLDER provided, ouch tries to create a new folder for the output results.

But sometimes this folder already exists, let's call this a top-level folder conflict when unpacking.

In this scenario, ouch should prefer renaming over the more destructive current default which is overwriting.

Current behavior (recently tweaked by @tommady at #959)

$ mkdir archive
$ ouch decompress archive.tar
Do you want to overwrite "archive"? [(Y)es/(n)o/(r)ename/(m)erge]
<USER PRESSES ENTER>
... OVERWRITES FOLDER ...

Suggested behavior

$ mkdir archive
$ ouch decompress archive.tar
Hande file conflict for "archive" folder: [(R)ename/(m)erge/(o)verwrite/(s)kip]
<USER PRESSES ENTER>
... RENAMES FOLDER ...

(Also renaming the other two options from yes and no to overwrite and skip to avoid the instictive push to type y and press enter, which is potentially destructive in the scenario of overwriting.)

Alternative

Automatically renamed top-level folder without asking. (not a big fan).


OBS: in the future, we'll have conflict resolution for each individual file that's unpacked, so, renaming will likely have to be an user-facing STDIN question anyways, but, this issue is specifically discussing the conflicts that we handle today before any major refac, which is only the top-level directory (named based on the input archive itself) conflict.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions