Robert Hiles

Thanks for closing the loop and sharing what fixed it, since that confirmation helps anyone hitting the same slowdown after an upgrade. Your finding is a good reminder to check real-time scanning before assuming the newer build itself is slower, especially when the settings have not changed. If the issue ever returns, comparing one run with the working folders temporarily excluded can quickly show whether scanning is involved again.

Sam makes a strong security point, because 777 is far too permissive to be a silent default for files coming from another system. Until the mapping changes, I would treat Windows-made TAR files as untrusted and extract them with permissions restricted by umask, then tighten anything sensitive with an explicit chmod afterward. A conservative default, such as the usual read and write for the owner only, would also be much safer than assuming every extracted file should be executable and writable by...

Thanks for putting this together, AlexS. The worked example for the 7z row makes the flag letters much easier to follow, especially how creation, access and modification times are shown in one place. One small suggestion is to add a short note near the top explaining that the output is a snapshot of the installed libraries, so readers know why an extra codec or format appears only after adding an external library. That context would help newcomers avoid wondering why their own tables look slightly...

That short clarification helps a lot, because reading n as a 1ns part makes the whole time value read as one timestamp instead of two separate pieces. A practical check is to compare the same file listed with different time formats, since the converted times should agree once the unit is understood. It would also help future readers if the listing help noted the unit next to that field, so the meaning is clear without needing to ask.

Thanks for following up on that timing test, since a clean before-and-after comparison is the clearest way to separate scanning from compression. If you try it, it would help to report the same archive, the same settings, and the timings for both versions with and without the exclusion, along with the antivirus product and version in use. It is also worth checking whether a second run is faster than the first, since that can show whether the slowdown is mainly a one-time scan of the new files rather...

This is a sensible suggestion, because consistent version numbers make it much easier for update tools to tell whether a newer release is actually installed. A single three-part format would also reduce confusion when comparing the two installers side by side. Until that changes, checking the build number in the program itself is a useful cross-check before assuming an update failed.

Igor's point about antivirus scanning is a useful lead, since the same settings should otherwise behave very similarly across these two versions. It would be worth timing the same archive with an antivirus exclusion for the 7-Zip executable and the source folders, then comparing that result with the current timing. If the gap mostly disappears, that points to repeated scanning rather than a change in compression itself.

A small safety check helps before running that batch step on a full set of folders: try it on two or three copies first and confirm each archive lands back in its own folder. If any filenames repeat across archives, check the extracted results carefully, since later extractions can overwrite earlier files in shared locations. Keeping a backup of the original archives until you have verified the output makes it easy to redo a folder without losing anything.