[Feature Request] Integrate Parchive for Recovery Records

[nkh0472]

Summary:
Add optional .par2 recovery record (and .sha256 checksum even better) generation to improve archive robustness and allow WinRAR-style repair for damaged files.

---

One major reason some users still prefer WinRAR over 7-Zip (see [this discussion]) is that WinRAR offers a built-in recovery record feature. This allows embedding a user-defined percentage of recovery data directly into the archive, enabling binary-level repair of damaged files.

In the open-source community, [Parchive] provides a powerful and well-established solution for this functionality. It has been developed and refined over many years, is stable, and has earned broad recognition.

As the saying goes, “a backup without regular verification is no backup at all” — you never know when a backup has already become corrupted.

This issue is particularly critical for 7-Zip archives with solid compression. A small binary error in a solid archive can render the entire archive unusable, unlike non-solid archives where damage is typically limited to the affected file.

This feature has been a recurring request in the 7-Zip community since at least 2003 (possibly even earlier) — see archived discussions here. It has been a genuine need for many users over the years, but Igor has never shown any intention of implementing it.

Since this project is an enhanced fork of 7-Zip, I’d like to request adding support for this highly practical and valuable feature.

---

Proposed Approach

• Option for .par2 file creation:
  Add a checkbox in the archive creation dialog to generate a same-named .par2 file, with a sub-option to set the recovery data percentage — similar to WinRAR.
  Implementation-wise, this could be achieved by invoking Parchive via command-line in the background.

• Optional .sha256 checksum creation: (not important)
  During compression, automatically create a .sha256 checksum file for all files in the archive, similar to the existing “Create checksum file” context menu option in 7-Zip for folders.
  This allows for quick verification of archive integrity; if corruption is detected, users could choose to proceed with Parchive recovery.
  Generating the checksum during compression — instead of after a file transfer — reduces disk I/O by avoiding re-reading large archives later.

---

Why This Matters

Currently, Parchive is a purely command-line tool, largely unknown to most users and with a steep learning curve.
Integrating it directly into the archive creation process would make recovery record generation as simple as a single checkbox, just like WinRAR.
The automatic checksum generation would also go beyond what most existing archive software offers, providing both preventive verification and recovery capabilities in one workflow.

[malvarenga123]

I believe an approach similar to WinRAR's recovery record would be preferable, as it allows for self-repairing archives by embedding parity data directly within the file. This concept is explicitly supported in the PAR3 specification: https://parchive.github.io/doc/Parity_Volume_Set_Specification_v3.0.html#par-inside-another-file

[nkh0472]

I believe an approach similar to WinRAR's recovery record would be preferable, as it allows for self-repairing archives by embedding parity data directly within the file. This concept is explicitly supported in the PAR3 specification: https://parchive.github.io/doc/Parity_Volume_Set_Specification_v3.0.html#par-inside-another-file

The introduction of any recovery record would be helpful.
However, for this embedded approach, I believe it should serve as a supplement to, not a priority replacement for, independent recovery files.
The reason is obvious: even the .par2 format is not yet widely adopted, and directly using .par3 files to replace .7z archives would introduce more severe compatibility issues, especially when you need to share files with others.
Just as on the current internet, essentially all download links that provide checksums use plain text or separate .sha files—this is the lowest-cost improvement without fatal drawbacks.

PS: I've encountered a situation where I sent someone a 7z file via email, and after multiple attempts, they kept complaining it was corrupted. It turned out I had sent a 7z file compressed with Zstd, while they were using a regular decompression tool (perhaps 7-Zip or something else). Therefore, I now lean towards forward-compatible improvements that serve the broadest possible audience.