decompress: Fix --dir erasing the whole folder
Fixes #820
From the test failures, it seems that disabling smart unpacking assumes one would be willing to clear the directory. This doesn't seem consistent with any other unpackers, e.g. tar where a change of folder just means setting where one wants the payloads written to.
Hi! If I understand, this enables Ouch to unpack something into an existing non-empty directory, makes sense.
This is related to https://github.com/ouch-org/ouch/pull/798, which implements merging folders (that wasn't a thing before), I considered making Ouch merge by default, and then you get asked prompts about further conflicts.
But I still haven't figured out what is the most intuitive, should merging only happen by default if --dir is provided? (If so, this PR is also merging when --dir is not provided.)
Do you have any thoughts on that? Would it be surprising if ouch decompress archive.tar unpacked files into existing folders? That could be hard to reverse if it wasn't intended.
Would it be surprising if ouch decompress archive.tar unpacked files into existing folders?
It was surprising for me that ouch decompress X.tar deletes a folder before unpacking on it. Tools like tar, 7-Zip, unzip etc. all decompress in the target directory with no issue, just printing out which file they're writing or overwriting.
Had I ran into this on my desktop instead of on CI, it could've destroyed my whole user directory, hence why I'd like to see this fixed.
Hey, I'm going to close this for now as I think I first need to improve the default behavior to merge folders by default instead of deleting them, then, I'll make sure the scenario you mentioned is covered.
Related to, and tracked at https://github.com/ouch-org/ouch/issues/813.
Thanks tho!!