This is a cache of https://sourceforge.net/p/sevenzip/discussion/45797/thread/b95432c7ac/. It is a snapshot of the page as it appeared on 2025-09-03T12:15:56.584+0200.
The default dictionary size values for 32-bit versions of LZMA/LZMA2 don't exceed 64 MB.
- 7-Zip now can calculate the following hash checksums: SHA-512, SHA-384, SHA3-256 and MD5.
- APM and HFS support was improved.
- If an archive update operation uses a temporary archive folder and the archive is moved to the destination folder, 7-Zip shows the progress of moving the archive file, as this operation can take a long time if the archive is large.
- The bug was fixed: 7-Zip File Manager didn't propagate Zone.Identifier stream for extracted files from nested archives (if there is open archive inside another open archive).
- Some bugs were fixed.
🎉
1
👍
11
Last edit: Igor Pavlov 2024-11-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Igor, thank you for the new version. I tested every new method + Blake2sp, XXH64 like this:
7z a -thash file.blake2sp folder
and checked like this:
7z t -thash file.blake2sp folder
Everything is fine, but why does 7-zip use in this case linux path separator / for file.hash instead of the Windows one \ ? For compatibility? For the modern hashers it's nothing but is there any switch to change the separators in this case?
And. yes,
SHA-384, SHA-512 are + 50% speed to SHA-256,
SHA3-256 is + 30% speed to SHA-256, without Intel SHA Extensions.
And I think guys will thank you for MD5 later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These hash text files formats are from linux. So we try to keep byte to byte compatibility with linux tools.
To check that 7-zip works correctly, we must use any another program to check calculated hashes.
To check created files in linux:
I meant that TC does OK, It can check the sums that were created with both commands:
7z a file.sha384 folder (linux path separators)
or
7z h -ba -scrcsha384 -slfhn -xtd Folder > File.sha384 (Windows path separators)
TC has a visual option to switch the separators for a sum creation, so It handles both fine.
Last edit: lelik007 2024-12-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ipavlov Igor, this command:
7z a file.sfv folder
is creating 7z file instead of .sfv
7z a -thash file.sfv folder works as it should be.
In the first case auto-detection for the extension doesn't work as I think.
The other checksum extensions work correctly - 7z detects them.
Last edit: lelik007 2024-12-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New version 7-Zip 24.09 supports hardware SHA-512 instructions.
If you have Windows with Qualcomm X Elite / X Plus processor or latest Intel Core Ultra Lunar Lake / Arrow Lake (285K/265K/245K), please run the following test from command line and post the results here to forum thread:
"C:\Program Files\7-Zip\7z" b -mmt1 -mm=hash -mtic=32 > 1.txt
Windows for ARM64 doesn't provide a simple way to detect SHA-512 instructions extension. So 7-Zip parses registry key value
And we need to check that it works correctly.
If you have older arm64 processor, you also can run this test and post results to check that it correctly detects SHA-512 extension absence.
Last edit: Igor Pavlov 2024-11-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks! SHA512 looks ok.
registry value was parsed: cp4030:1221111110212120:SHA256:SHA512
Also some interesting about Snapdragon(R) X Elite pareformance, that CRC32:64 is only 9 GB/s - it means 3-cycles latency for crc32 instruction, like in Apple M1, and modern Cortex is 3 times faster.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also I see that some integer benchmark workload results (like MD5,SHA1) are slow on X Elite. Apple M1 is faster.
But maybe it's because of slow MSVC compiler.
If you have WSL in that computer, please compare benchmarks for both Windows and linux version (via WSL) of 7-Zip:
7zb-mmt1>win.txtwsl./7zzb-mmt1>lin.txt
Last edit: Igor Pavlov 2025-01-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the long reply. Here are the results.
TL:DR: the linux results are higher but not that much (around 5-10% higher). I don't know if this expected.
Here are the results. I have put them in a single txt file. One thing I have noticied is that when I run the test, I do not have one CPU core max out at 100%. Instead I have two CPU cores at around 50% each.
I do not know why I have this behavior with 7zip since other programs seems fine. Maybe it can explain why the results are a bit low?
System can switch working cores for single thread programs.
There is switch -stm1 in 7-zip that can set affinity to first core. But I don't think that it will change results.
About results. ARM64 code from MSVS compiler is slow for most HASH calculation workloads of 7-Zip. GCC (WSL) is 20-60% faster.
Even X64 (MSVS) emulated code is faster than ARM64 (MSVS) for HASH code. Probably I'll look the code later to find the reason of bad performance of MSVS-ARM64.
Last edit: Igor Pavlov 2025-02-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip 24.09 was released.
Download
7-Zip for 64-bit Windows x64:
https://7-zip.org/a/7z2409-x64.exe
7-Zip for 32-bit Windows x86:
https://7-zip.org/a/7z2409.exe
7-Zip for 64-bit Windows ARM64:
https://7-zip.org/a/7z2409-arm64.exe
7-Zip Extra: standalone console version, 7z DLL, Plugin for Far Manager:
https://7-zip.org/a/7z2409-extra.7z
7-Zip (console version) for 64-bit linux x86-64 (AMD64):
https://7-zip.org/a/7z2409-linux-x64.tar.xz
7-Zip (console version) for 32-bit linux x86:
https://7-zip.org/a/7z2409-linux-x86.tar.xz
7-Zip (console version) for 64-bit linux ARM64:
https://7-zip.org/a/7z2409-linux-arm64.tar.xz
7-Zip (console version) for 32-bit linux ARM:
https://7-zip.org/a/7z2409-linux-arm.tar.xz
7-Zip (console version) for macOS (ARM64 and x86-64):
https://7-zip.org/a/7z2409-mac.tar.xz
What's new in 7-Zip 24.09:
The default dictionary size values for 32-bit versions of LZMA/LZMA2 don't exceed 64 MB.
- 7-Zip now can calculate the following hash checksums: SHA-512, SHA-384, SHA3-256 and MD5.
- APM and HFS support was improved.
- If an archive update operation uses a temporary archive folder and the archive is moved to the destination folder, 7-Zip shows the progress of moving the archive file, as this operation can take a long time if the archive is large.
- The bug was fixed: 7-Zip File Manager didn't propagate Zone.Identifier stream for extracted files from nested archives (if there is open archive inside another open archive).
- Some bugs were fixed.
Last edit: Igor Pavlov 2024-11-30
Igor, thank you for the new version. I tested every new method + Blake2sp, XXH64 like this:
7z a -thash file.blake2sp folder
and checked like this:
7z t -thash file.blake2sp folder
Everything is fine, but why does 7-zip use in this case linux path separator / for file.hash instead of the Windows one \ ? For compatibility? For the modern hashers it's nothing but is there any switch to change the separators in this case?
And. yes,
SHA-384, SHA-512 are + 50% speed to SHA-256,
SHA3-256 is + 30% speed to SHA-256, without Intel SHA Extensions.
And I think guys will thank you for MD5 later.
These hash text files formats are from linux. So we try to keep byte to byte compatibility with linux tools.
To check that 7-zip works correctly, we must use any another program to check calculated hashes.
To check created files in linux:
Last edit: Igor Pavlov 2024-11-30
TC for example doesn't mind linux separators, but I don't have linux even in WSL form to check the native commands.
Maybe someone should report TC developers about that problem.
I meant that TC does OK, It can check the sums that were created with both commands:
7z a file.sha384 folder (linux path separators)
or
7z h -ba -scrcsha384 -slfhn -xtd Folder > File.sha384 (Windows path separators)
TC has a visual option to switch the separators for a sum creation, so It handles both fine.
Last edit: lelik007 2024-12-01
Thanks!
Does 24.09 fix CVE-2024-11477?
CVE-2024-11477 was fixed in 7-Zip v24.07 (2024-06-19)
https://www.7-zip.org/history.txt
Great that it was fixed so quickly, thanks @ipavlov!
@ipavlov Igor, this command:
7z a file.sfv folder
is creating 7z file instead of .sfv
7z a -thash file.sfv folder works as it should be.
In the first case auto-detection for the extension doesn't work as I think.
The other checksum extensions work correctly - 7z detects them.
Last edit: lelik007 2024-12-01
@ipavlov 7z i shows:
0 256 231 SHA3-256
there should be hash size in bytes:
0 32 231 SHA3-256 as for:
0 32 A SHA256
Yes, I'll fix it.
Actually these numbers are for
icommand only. So real hash size is correct in another code.Thanks!
every version of 7-zip is like a great milestone but version 24.09 is absolutely perfect.
SHA-512 TEST
New version 7-Zip 24.09 supports hardware SHA-512 instructions.
If you have Windows with Qualcomm X Elite / X Plus processor or latest Intel Core Ultra Lunar Lake / Arrow Lake (285K/265K/245K), please run the following test from command line and post the results here to forum thread:
Windows for ARM64 doesn't provide a simple way to detect SHA-512 instructions extension. So 7-Zip parses registry key value
And we need to check that it works correctly.
If you have older arm64 processor, you also can run this test and post results to check that it correctly detects SHA-512 extension absence.
Last edit: Igor Pavlov 2024-11-30
Here are the results on my laptop as an attachment. It seems to detect the SHA512 extension correctly.
Thanks!
SHA512looks ok.registry value was parsed:
cp4030:1221111110212120:SHA256:SHA512Also some interesting about
Snapdragon(R) X Elitepareformance, that CRC32:64 is only 9 GB/s - it means 3-cycles latency for crc32 instruction, like in Apple M1, and modern Cortex is 3 times faster.Also I see that some integer benchmark workload results (like MD5,SHA1) are slow on X Elite. Apple M1 is faster.
But maybe it's because of slow MSVC compiler.
If you have
WSLin that computer, please compare benchmarks for both Windows and linux version (via WSL) of 7-Zip:Last edit: Igor Pavlov 2025-01-22
Sorry for the long reply. Here are the results.
TL:DR: the linux results are higher but not that much (around 5-10% higher). I don't know if this expected.
Last edit: Igor Pavlov 2025-02-12
please run another commands:
Also if your system supports
x64emulation (prism), unpack7-Zip x64installer to some folder, and runx64version:There is some error with timers in wsl:
cpu usage column must be 100%.
1T CPU Freq (MHz)freq must be 3400 instead of 3650.Last edit: Igor Pavlov 2025-02-12
Here are the results. I have put them in a single txt file. One thing I have noticied is that when I run the test, I do not have one CPU core max out at 100%. Instead I have two CPU cores at around 50% each.
I do not know why I have this behavior with 7zip since other programs seems fine. Maybe it can explain why the results are a bit low?
Thanks for tests!
System can switch working cores for single thread programs.
There is switch
-stm1in 7-zip that can set affinity to first core. But I don't think that it will change results.About results. ARM64 code from MSVS compiler is slow for most HASH calculation workloads of 7-Zip. GCC (WSL) is 20-60% faster.
Even X64 (MSVS) emulated code is faster than ARM64 (MSVS) for HASH code. Probably I'll look the code later to find the reason of bad performance of MSVS-ARM64.
Last edit: Igor Pavlov 2025-02-13
Small typo - all Windows installel's (SFX and MSI) included old redaction readme.txt for v24.09 :) - find insorg at forum.ru-board.com.
thx Igor Pavlov for a 7zip update! :D :D
The 24.09 version of 7zr.exe got flagged by my Windows 11 Pro 24H2 Windows Defender as having a virus (hope it's a false positive):
Detected: Trojan:Win32/Wacatac.H!ml
https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3AWin32%2FWacatac.H!ml&threatid=2147814523
Where are those compression levels/dictionaries defined, if I'd like to change them?