0.8.0

[marcospb19]

0.8.0

Updating to 0.8.0 is mandatory, it fixes a serious bug where ouch would think there is a conflict with the current folder and ask the user wanted to overwrite it (possibly deleting user files in the process).

Next up you should expect some security improvements, like Landlock sandboxing and safeguards against reading malicious archives.

Packaging

• Reproducible builds (Make ouch builds reproducible #973).

New Features

• Releases: add Apple Silicon macOS (aarch64-apple-darwin) to assets.
• Unpack into new folder by default (fix decompression without dir  #962).
• Add --here flag to unpack into current directory (fix decompression without dir  #962).
• List: show symlink targets (for tar and zip) (list: show symlink targets (for tar and zip) #934)
• Add aliases for ebooks (.epub) ((reopen #977) add alias for ebooks (epub) #981)

Improvements

• Improve options for solving conflicts (feat: improve display of overwrite choices #959 #964)
• Report mtime-set errors for .7z as warnings (fix multiple panics on extraction #950)
• list: also display symlink targets (list: show symlink targets (for tar and zip) #934)
• Improve man pages for subcommands (build: improve man pages for subcommands #980)

Bug Fixes

• Fix Ouch trying to overwrite current directory (fix decompression without dir  #962)
• Fix various panics not handled gracefully (fix multiple panics on extraction #950)
• Handle GNUSparse archive entries during tar decompression (Handle GNUSparse archive entries during tar decompression #975)

New Contributors

• @pavelzw made their first contribution in Use cargo build --locked #957
• @curious-rabbit made their first contribution in fix multiple panics on extraction #950
• @venoosoo made their first contribution in fix:unify directory extraction messages for zip and tar #937
• @kilianbartz made their first contribution in Handle GNUSparse archive entries during tar decompression #975

And a big shoutout to @valoq and @tommady for the huge help.

Full Changelog: 0.7.1...0.8.0

---

This discussion was created from the release 0.8.0.

[roland-5]

@marcospb19 Not sure if this is a problem or it's working like was designed, but for example: if I have one archive1 with folder name folder123 and there are few different files and file with name text.txt and there is second archive (archive2) that have totally different files but have text.txt file too, but it's different in inside, and you choose merge folders, you have files from both archives without any deletions, but previous text.txt from archive1 file will be replaces with text.txt from archive2. Is it possible to warn me, there are files with the same name, so merging two archives in this one folder delete previous files if they have the same names?

[marcospb19]

Working like designed, but definitely not ideal 👍.

There are three cases where this can happen:

1. decompress and merge (your case)
2. decompress with '--dir .'
3. decompress with '--here' (equivalent to point 2)

It's like conflict detection only works at the folder level, past that point each format just does their thing, I believe overwriting might not be a consistent behavior between all different archive formats.

In order to implement conflict check and proper resolutions for all files when decompressing, I started working on a PR that looked like this: instead of letting every format do their thing, they all would use a new common interface for every file that is unpacked, and that supports renaming too, that also means we need to move the specific format sanity/safety checks to our code cause we'd be writing the files ourselves, it's doable, but has impressive emerging complexity and was postponed a little bit.

Together with sandboxing, I think working on this might be a good priority for the project.

[roland-5]

First of all, thank you and the rest of the team for your work on Ouch. I was introduced to it in version 0.2 and started using it regularly with 0.3. I'm glad you're all still working on the project and improving it, it's really easy on external machines to work with archives, if I don't have sudo.

Sure, I understand the complexity of the problem and the amount of work involved, and I've made a note to remember that for the relevant archives.

[marcospb19]

Thanks! I know you've been here for a long time! :)