fix: prevent destructive overwrite of decompression directories - #1044
Conversation
wat, uh, oke, Imma ignore that |
Did you choose that by accident and had an unintended deletion? Do you think the conflict message was confusing and could be improved? |
|
No, I did not lose data myself; I reproduced the behavior reported in #1043. The prompt says |
71f8ab6 to
bc5e0df
Compare
marcospb19
left a comment
There was a problem hiding this comment.
I was thinking of renaming it to delete instead of overwrite so that we didn't remove the capability of deleting it.
But maybe you're right, we should just remove any possibility of messing up while using ouch, even if that means requiring the user to manually run some rm in corner cases.
|
I rebased and now CI is failing, I'll be trying to fix. |
|
Thanks! |
Closes #1043.
Summary
overwritechoice when a decompression conflict target is a directoryrename,merge, andskipfor directory conflicts while preservingoverwritefor actual file conflictsValidation
cargo test --lockedcargo test --locked --no-default-featurescargo test --locked --no-default-features --features unrar,use_zlib,use_zstd_thincargo clippy --locked --all-targets -- -D warningscargo clippy --locked --no-default-features --all-targets -- -D warningscargo +nightly fmt -- --check