https://bugs.kde.org/show_bug.cgi?id=382599
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #26 from [email protected] --- (In reply to Brandow from comment #25) Data point on the cli7z progress question, since the thread keeps coming back to "7z can display progress, Ark just doesn't parse it". I measured what 7z actually emits, with 7-Zip 26.03: test.7z (407 entries, 191 MiB, Solid = +, 3 blocks) -> 0% and nothing else; goes straight to "Everything is Ok" test.7z (20,004 entries, 144 MiB, Solid = +, 2 blocks) -> 0% then a single 100% at the very end, as part of the "Everything is Ok" line Both archives are solid, which I think is the key point: 7z decompresses a solid block as a single stream, so it has no per-file progress to report and can only emit a percentage at block boundaries. A solid archive is the default output of "7z a", so this is the common case, not an edge case. There is also a parsing bug waiting regardless: CliInterface::handleLine() (cliinterface.cpp:809) takes mid(pos-2, 2) after the '%', so a final "100%" is read as "00" -> 0. So enabling captureProgress for cli7z looks like a dead end for solid archives: you would get 0% at the start and a misparsed 0% at the end, versus today's 0% and a correct 100% from the job completing. I did check one workaround that does work. Disabling the cli7z plugin routes 7z through libarchive instead: [Plugins] disabledPlugins=kerfuffle_cli7z With that, 7z progress becomes monotonic and reaches 100%, and I diffed the output against cli7z's -- byte-identical (same file count, same sizes, diff -r clean). Caveat: cli7z is the only backend that can *create* .7z and libarchive cannot write 7z, so that is not a viable default, only a troubleshooting step. But it does mean the libarchive 7z reader is solid enough to be worth considering as a real path forward for extraction. -- You are receiving this mail because: You are watching all bug changes.
