There are tests on the network, 7-zip 9.35--15.05 compression rate and speed are fast, while older versions and newer versions have no such version of compression rate high speed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right mouse CRC Sha The checksum information created cannot be copied, nor can it be aligned with the existing checksum value on the disk. Very inconvenient.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip now reserves file space before writing to file (for extraction from archive).
It can reduce file fragmentation.
OMG FINALLY! I've been waiting forever for this to get fixed https://sourceforge.net/p/sevenzip/feature-requests/981/
I can confirm it's indeed working, BUT it seems it only sends SetEndOfFile when file is larger than 4KB. Is this intended behavior? Did you want to skip sending this if file is smaller that cluster? If yes, then 7zip should first check destination's cluster size, I have mine set to 64KB for example on one partition that I tested this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ssmaller than cluster size are not fragmented. And smaller than 900 bytes if I remember correctly are stored in MFT. Bu still, 7zip should check destination's cluster size to know when to send SetEndOfFile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another 7-Zip code actually writes data with chunks (32KB for deflate and more for another methods). So windows knows that file is larger than small cluster size (if cluster size is just 1 KB). So I suppose that it's low probability that you will have fragmented file (for files smaller than 4 KB), even if cluster size is just 1 KB.
You can test it.
7-Zip can show the number of fragments in "Blocks" column, if you open raw image of NTFS partition with "administrator" rights:
\\.\E:\
\\.\PhysicalDrive0\
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code for ZIP headers parsing was rewritten. There were big changes in that code. So if something doesn't work with ZIPs now, please notify me.
There were problems with zips created in macos.
There were problems with some rare case zip64 archives.
Additional timestamp handling in UX extra field (Unix Extra).
Now 7-Zip shows IDs of extra fields in "Characteristics" column
for ZIP and RAR.
7-Zip now uses Windows encoding instead of OEM for passwords for ZipCrypto unpacking.
It's possible to use "xz" method in ZIP with -mm=xz.
Deflate decoding can be slightly faster now.
bzip2 decoding can be faster now.
DMG support was improved.
7-Zip supports ns precision in EXT4 and RAR's timestamps (RARs from linux and android). It's rounded to 100 ns precision (Windows precision) in 7-Zip.
7-Zip File Manager.
You can switch timestamp precision in View. But that setting is not stored in registry still.
Additional File commands now are available by default:
Open Inside #
Open Inside *
and you can use them when some archive is open already.
Previous 7-Zip could crash for drag drop to open archive.
7-Zip could crash for some "bad" archives (7z archives and other types).
new switches:
-snt[-] Replace trail dots and spaces in file names for Extract operation
-mtr- : disable file attributes storing (7z archives only)
Better compatibility with VS 2015/2017 compilers in source code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is nice to see arbitrary time precision in 7zFM, thanks! However, I suggest giving a name to the corresponding View menu subitem in a release version of 7-Zip. For example: View -> Timestamp format -> <current_time>. By the way, showing current time is useful, but a menu item that changes from run to run may be misleading to some users. (However, beta testers can now say that 7-Zip runs like a clockwork...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I meant specifying a fixed date like 01.01.1900 00:00:00. It is static and does not require calling API. Though your variant with the current time is more useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2017-05-05
I think Igor simply means the addition of menus, each menu item must have a label (i.e. "Timestamp format" in this example), and a translation must be in each of 87 files, meaning Igor must find ~86 other people to help translate, or translate the string ~86 times by looking online at many translation and dictionary and programming sites to ensure correct translation. Time consuming.
Last edit: 2017-05-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip File Manager.
You can increase the file type column labels. Open a compressed document can be sorted by type. Facilitates the decompression of the same type of file.
Would you like to view WinRAR's comments on the right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are the additional formats added by Tino Reichhardt (sources and changes in https://github.com/mcmilk/7-Zip-zstd) added to 7zip 17? If they aren't (yet): will they be added?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's self extract ZIP inside EXE.
ZIP archive is OK.
But EXE (PE) headers also contain checksum.
And 7-Zip reports that this EXE checksum is not correct.
Most programs just ignore that checksum in EXE (PE) file.
But 7-Zip checks it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-zip 64bit (17.00 beta and previous) Windows 10 Pro
wrong information is displayed about adding file, when using zip compression
see attachment and marked place - should show file "system.new.dat" (big file)
I assume something like the following (simplified):
7zip main thread is in a loop after showing the dialog:
checks for the next file to process
if the maximum numbers of processing threads (set in the "add to archive dialog") is not reached: change the dialog to show the file name, start a new thread and pass the file handle
if all files are processed exit the loop, close the dialog
In the case n00b provided the first thread handles the big file, the second one the small one.
I'd suggest the following: Show what 7zip does by adding one label for each working thread (guessing 96 threads aren't supported).
Another option is to split the main loop into another thread.
7zip main thread in a loop after starting the dialog thread
checks for the next file to process
if the maximum numbers of processing threads (set in the "add to archive dialog") is not reached: start a new thread and pass the file handle
if all files are processed exit the loop, terminate the dialog thread
All processing threads:
send a message with the currently processed file to the dialog thread
process the file
send a message "finished" to the dialog thread
Dialog thread:
when started: show the dialog (or use the handle passed from the from the main thread)
when a processing thread comes in put it in a vector
when a processing thread sends its terminate message remove it from the vector
whenever the vector is changed show the file name of the last added entry in the dialog
Thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are tests on the network, 7-zip 9.35--15.05 compression rate and speed are fast, while older versions and newer versions have no such version of compression rate high speed
Right mouse CRC Sha The checksum information created cannot be copied, nor can it be aligned with the existing checksum value on the disk. Very inconvenient.
Press Ctrl+C while in the information dialog. It also works for all Windows applications.
Thank you Igor, this is very important (it reduces assuredly the file fragmentation) :)
It can reduce file fragmentation.
OMG FINALLY! I've been waiting forever for this to get fixed https://sourceforge.net/p/sevenzip/feature-requests/981/
I can confirm it's indeed working, BUT it seems it only sends SetEndOfFile when file is larger than 4KB. Is this intended behavior? Did you want to skip sending this if file is smaller that cluster? If yes, then 7zip should first check destination's cluster size, I have mine set to 64KB for example on one partition that I tested this.
Small files probably are not fragmented.
So no need for additional calls for them.
Ssmaller than cluster size are not fragmented. And smaller than 900 bytes if I remember correctly are stored in MFT. Bu still, 7zip should check destination's cluster size to know when to send SetEndOfFile.
Another 7-Zip code actually writes data with chunks (32KB for deflate and more for another methods). So windows knows that file is larger than small cluster size (if cluster size is just 1 KB). So I suppose that it's low probability that you will have fragmented file (for files smaller than 4 KB), even if cluster size is just 1 KB.
You can test it.
7-Zip can show the number of fragments in "Blocks" column, if you open raw image of NTFS partition with "administrator" rights:
It might be interesting to know some details about the improvements. I guess these may be timestamp handling and/or speed optimizations.
I also appreciate the ability to reserve file space. And 7-Zip still remains compatible with Windows 2000. Cool!
Some additional details about changes:
The code for ZIP headers parsing was rewritten. There were big changes in that code. So if something doesn't work with ZIPs now, please notify me.
There were problems with zips created in macos.
There were problems with some rare case zip64 archives.
Additional timestamp handling in UX extra field (Unix Extra).
Now 7-Zip shows IDs of extra fields in "Characteristics" column
for ZIP and RAR.
7-Zip now uses Windows encoding instead of OEM for passwords for ZipCrypto unpacking.
It's possible to use "xz" method in ZIP with
-mm=xz.Deflate decoding can be slightly faster now.
bzip2 decoding can be faster now.
DMG support was improved.
7-Zip supports ns precision in EXT4 and RAR's timestamps (RARs from linux and android). It's rounded to 100 ns precision (Windows precision) in 7-Zip.
7-Zip File Manager.
You can switch timestamp precision in View. But that setting is not stored in registry still.
Additional File commands now are available by default:
and you can use them when some archive is open already.
Previous 7-Zip could crash for drag drop to open archive.
7-Zip could crash for some "bad" archives (7z archives and other types).
new switches:
Better compatibility with VS 2015/2017 compilers in source code.
I hope someone uses a fuzzer on the new parsing code.
Thanks Igor.
It is nice to see arbitrary time precision in 7zFM, thanks! However, I suggest giving a name to the corresponding
Viewmenu subitem in a release version of 7-Zip. For example:View -> Timestamp format -> <current_time>. By the way, showing current time is useful, but a menu item that changes from run to run may be misleading to some users. (However, beta testers can now say that 7-Zip runs like a clockwork...)I try to make new things without new language strings.
If there is new string, we have to update 87 translation files.
I meant specifying a fixed date like
01.01.1900 00:00:00. It is static and does not require calling API. Though your variant with the current time is more useful.I think Igor simply means the addition of menus, each menu item must have a label (i.e. "Timestamp format" in this example), and a translation must be in each of 87 files, meaning Igor must find ~86 other people to help translate, or translate the string ~86 times by looking online at many translation and dictionary and programming sites to ensure correct translation. Time consuming.
Last edit: 2017-05-05
7-Zip File Manager.
You can increase the file type column labels. Open a compressed document can be sorted by type. Facilitates the decompression of the same type of file.
Would you like to view WinRAR's comments on the right?
Hey Igor! Are there any plans for UI refresh (Windows version)? Especially the icons of archives, toolbar etc.
Thanks for the improvements!
Are the additional formats added by Tino Reichhardt (sources and changes in https://github.com/mcmilk/7-Zip-zstd) added to 7zip 17? If they aren't (yet): will they be added?
i get checksum error with these files
http://downloadmirror.intel.com/18713/eng/PROWin32.exe
http://downloadmirror.intel.com/18713/eng/PROWinx64.exe
winrar extracts them without any notice.
is it something important?
Last edit: serif rodop 2017-05-03
It's self extract ZIP inside EXE.
ZIP archive is OK.
But EXE (PE) headers also contain checksum.
And 7-Zip reports that this EXE checksum is not correct.
Most programs just ignore that checksum in EXE (PE) file.
But 7-Zip checks it.
Thank you for the new release! There's no error up to now.
7-zip 64bit (17.00 beta and previous) Windows 10 Pro
wrong information is displayed about adding file, when using zip compression
see attachment and marked place - should show file "system.new.dat" (big file)
Last edit: n00b 2017-05-03
It shows the name of last file that was open.
But zip code is multithreaded. So 7-Zip opens small file while another thead is working for big file.
I assume something like the following (simplified):
7zip main thread is in a loop after showing the dialog:
In the case n00b provided the first thread handles the big file, the second one the small one.
I'd suggest the following: Show what 7zip does by adding one label for each working thread (guessing 96 threads aren't supported).
Another option is to split the main loop into another thread.
7zip main thread in a loop after starting the dialog thread
All processing threads:
Dialog thread:
Thoughts?