What's new:
- 7-Zip now supports LZMA2 compression method.
- 7-Zip now supports XZ archives.
- 7-Zip now can unpack NTFS, FAT, VHD and MBR archives.
- 7-Zip now can unpack GZip, BZip2, LZMA, XZ and TAR archives from stdin.
- 7-Zip now can open/copy/compress disk images (like \\.\c:) from \\.\ folder.
- 7-Zip File Manager now doesn't use temp files to open nested archives
stored without compression.
- New -scrc switch to calculate total CRC-32 during extracting / testing.
- Some bugs were fixed.
Don't use this alpha version for important data. Call "Test" command after each compressing operation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you have access to Posix/Linux systems, please check the compatibility between XZ Utils and 7-Zip. Just create some XZ archives with one program, and try to extract with another.
You can get XZ Utils from: http://tukaani.org/xz/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
when I rightclick 7zFM.exe (32-Bit, April 18th 2009) it shows "Fileversion: 9.0.0.0". But when I start it with double-click, it shows "Version 4.65" in about-dialog (latest installed version of 7-zip on my system)?!
So (if I'm right) -> who ever wants to test it (version 9.0.0.0), be sure to have a "clean" system (no previous versions of 7-zip in use).
Best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WinXp SP3 P4ht-3GHg, 512 mb RAM, xz-ultra compression of 840 mb file ISO, after about 5% progress I try cansel operation some times, pressinf "cansel-yes" and nothing happen, Ctrl+Alt+Del help. I see how my HDD read hardly.
Спасибо.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think there is a memory leak. When I try to compress a big folder (about 30GB), using Ultra compression with LZMA2, 4 threads (other settings unchanged), it tells me it will use 1389MB of memory...
33% through, I noticed it uses 3345MB, with over 5GB of Commit size.
monitoring the progress, @39% it used 4697MB, with over 6.5GB of commit size...
@ 50%, 5647MB, with 8GB commit...
Looks to me that once in a while, maybe after the size of the Solid block, it starts over without clearing the memory used when compressing the older block...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: No unexpected increase in memory usage when "Solid Block Size" = "Solid", although it still uses more memory then initially reported as needed by the GUI (uses 2386MB)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oddly enough, the second thing I tried after creating an LZMA2 archive was try to extract a split file (.7z.001). Both 7z.exe and 7zG.exe in both x64 and x86 report "The parameter is incorrect". 7zFM.exe in both archs handles these files ok.
Also, I'm curious if you have a plan to eventually make LZMA2 the default method for 7z files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, I want to thank you for the build, is all OK in My Machine, I have installed the 9.00 beta 32 bits in Wine under Linux, using Fedora Core, and it´s all OK.
Well, during the use of LZMA2, (xz), everything works fine, the limit of 2Gb memory does not cause any problem with 16MB dictionary size, but when I increase it to 32 MB, I have to decrease the number of threads.
Multiplying the number of memory X threads used to compress the archive, I can know the maximum amount of memory LZMA2 will use to compress files, thus won´t blowing the memory window.
Interesting, LZMA2 caches a portion of the file in the entire memory before streaming it to compress, and after all of the chunks is read and compressed, let the system reallocates the ram, and then the system file cache allocates more ram. (@aitam).
I guess the allocation in memory, is one thing, file cache, is another.
Aitam , is your windows reporting only the pages allocated or then reporting file cache + amount of ram used to compress the file ?
It´s not really a problem if the file cache increases and you have sufficient amount of ram to handle it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1.LZMA2 SFX archives are not suported
2.When add executable file(*.exe,*.dll,...) to LZMA2 archive "BCJ2 LZMA2:xxx LZMA:xxx LZMA:xxx". LZMA2 is used for the first stream only or information module issue or OK?
multithread compression is great. I'll test it later on Core i7 @3.8GHz(4 cores,8 threads) with 12 GB RAM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Xz only supports one file, I have tested with a large file (32 GB BKF) and it ends with 8 GB size. It only works with one file, If I plan to use a directory then I need to choose store on any *zip version before starting to convert to Xz ? ( A Lot of space required )
Well, There is a button, .tarXz to handle this operation, but why the button disappear under Windows and everything works fine under wine ?
Is there a way to make a XIP like operation (execute in place) on the files, storing the structure of the names and directories in another file to generate the dictionary before we start to convert them all into a large Xz ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It´s all Ok under Wine, and under Windows too. FC10 X84_64, Ubuntu and Windows Xp 32 Bits. I didn´t have other operating system to test. I will continue on testing and using. LZMA2 is very stable, all ok.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would there be any problems installing both 64-bit and 32-bit versions? Some 32-bit programs that are able to open windows (such as uTorrent, right-clicking and hitting open file location) open the explorer window in "32-bit".....with only 64-bit installed (the previous stable version) I was unable to right click anything in that window opened by uTorrent to extract or compress archives, the 7-zip menu did not appear. Browsing to that directory after opening Computer though, worked fine and showed the 7-zip menu.
Was this issue addressed in this alpha or is installing both 64-bit and 32-bit the best way to go about fixing it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip 9.00 alpha was released.
7-Zip for 32-bit Windows:
http://dl.7-zip.org/7z900a.exe
7-Zip for 64-bit Windows x64:
http://dl.7-zip.org/7z900a-x64.msi
What's new:
- 7-Zip now supports LZMA2 compression method.
- 7-Zip now supports XZ archives.
- 7-Zip now can unpack NTFS, FAT, VHD and MBR archives.
- 7-Zip now can unpack GZip, BZip2, LZMA, XZ and TAR archives from stdin.
- 7-Zip now can open/copy/compress disk images (like \\.\c:) from \\.\ folder.
- 7-Zip File Manager now doesn't use temp files to open nested archives
stored without compression.
- New -scrc switch to calculate total CRC-32 during extracting / testing.
- Some bugs were fixed.
Don't use this alpha version for important data. Call "Test" command after each compressing operation.
XZ format provides one file->one file compression (like, gzip and bzip2):
http://tukaani.org/xz/xz-file-format.txt
If you have access to Posix/Linux systems, please check the compatibility between XZ Utils and 7-Zip. Just create some XZ archives with one program, and try to extract with another.
You can get XZ Utils from:
http://tukaani.org/xz/
Thank you Igor!
small question: Why is there that huge jump in version number? Is that the version we have expected to be released under "5.0"?
9.* means 2009.
So we could also call it 4.67 (?)
:)
Hello everyone,
when I rightclick 7zFM.exe (32-Bit, April 18th 2009) it shows "Fileversion: 9.0.0.0". But when I start it with double-click, it shows "Version 4.65" in about-dialog (latest installed version of 7-zip on my system)?!
So (if I'm right) -> who ever wants to test it (version 9.0.0.0), be sure to have a "clean" system (no previous versions of 7-zip in use).
Best regards!
button cancel (compressing xz) not working
"Cancel" button works in my tests.
So write exact case when it doesn't work. What settings do you use?
And what is your RAM size?
WinXp SP3 P4ht-3GHg, 512 mb RAM, xz-ultra compression of 840 mb file ISO, after about 5% progress I try cansel operation some times, pressinf "cansel-yes" and nothing happen, Ctrl+Alt+Del help. I see how my HDD read hardly.
Спасибо.
Try to reduce dictionary size to 16 MB / 8 MB.
I think there is a memory leak. When I try to compress a big folder (about 30GB), using Ultra compression with LZMA2, 4 threads (other settings unchanged), it tells me it will use 1389MB of memory...
33% through, I noticed it uses 3345MB, with over 5GB of Commit size.
monitoring the progress, @39% it used 4697MB, with over 6.5GB of commit size...
@ 50%, 5647MB, with 8GB commit...
Looks to me that once in a while, maybe after the size of the Solid block, it starts over without clearing the memory used when compressing the older block...
P.S: the increase in memory usage doesn't happen gradually, but in "jumps"...
Update: No unexpected increase in memory usage when "Solid Block Size" = "Solid", although it still uses more memory then initially reported as needed by the GUI (uses 2386MB)
Oddly enough, the second thing I tried after creating an LZMA2 archive was try to extract a split file (.7z.001). Both 7z.exe and 7zG.exe in both x64 and x86 report "The parameter is incorrect". 7zFM.exe in both archs handles these files ok.
Also, I'm curious if you have a plan to eventually make LZMA2 the default method for 7z files.
First, I want to thank you for the build, is all OK in My Machine, I have installed the 9.00 beta 32 bits in Wine under Linux, using Fedora Core, and it´s all OK.
Well, during the use of LZMA2, (xz), everything works fine, the limit of 2Gb memory does not cause any problem with 16MB dictionary size, but when I increase it to 32 MB, I have to decrease the number of threads.
Multiplying the number of memory X threads used to compress the archive, I can know the maximum amount of memory LZMA2 will use to compress files, thus won´t blowing the memory window.
Interesting, LZMA2 caches a portion of the file in the entire memory before streaming it to compress, and after all of the chunks is read and compressed, let the system reallocates the ram, and then the system file cache allocates more ram. (@aitam).
I guess the allocation in memory, is one thing, file cache, is another.
Aitam , is your windows reporting only the pages allocated or then reporting file cache + amount of ram used to compress the file ?
It´s not really a problem if the file cache increases and you have sufficient amount of ram to handle it.
Igor, thank You!
I started using new 9.00 alpha version.
1.LZMA2 SFX archives are not suported
2.When add executable file(*.exe,*.dll,...) to LZMA2 archive "BCJ2 LZMA2:xxx LZMA:xxx LZMA:xxx". LZMA2 is used for the first stream only or information module issue or OK?
multithread compression is great. I'll test it later on Core i7 @3.8GHz(4 cores,8 threads) with 12 GB RAM
No need to use LZMA2 for additional streams of BCJ2
Xz only supports one file, I have tested with a large file (32 GB BKF) and it ends with 8 GB size. It only works with one file, If I plan to use a directory then I need to choose store on any *zip version before starting to convert to Xz ? ( A Lot of space required )
Well, There is a button, .tarXz to handle this operation, but why the button disappear under Windows and everything works fine under wine ?
Is there a way to make a XIP like operation (execute in place) on the files, storing the structure of the names and directories in another file to generate the dictionary before we start to convert them all into a large Xz ?
- Xz only supports one file, I have tested with a large file (32 GB BKF) and it ends with 8 GB size.
So was it OK?
You can call
7z t z.xz -scrc
and calculate crc filr 7-Zip FM to compare.
for small files you can call something like this:
7z a a.tar files\* -so | 7z a a.tar.xz -si
It´s all Ok under Wine, and under Windows too. FC10 X84_64, Ubuntu and Windows Xp 32 Bits. I didn´t have other operating system to test. I will continue on testing and using. LZMA2 is very stable, all ok.
Would there be any problems installing both 64-bit and 32-bit versions? Some 32-bit programs that are able to open windows (such as uTorrent, right-clicking and hitting open file location) open the explorer window in "32-bit".....with only 64-bit installed (the previous stable version) I was unable to right click anything in that window opened by uTorrent to extract or compress archives, the 7-zip menu did not appear. Browsing to that directory after opening Computer though, worked fine and showed the 7-zip menu.
Was this issue addressed in this alpha or is installing both 64-bit and 32-bit the best way to go about fixing it?
tried to compress nero 9.2.6.0 unpacked (1,973,508,786 bytes in 1052 files, 56 folders), using 7-zip 9.00 alpha x64:
method=ultra
dict. size=512M
fb=273
solid size=unlimited
LZMA, 2 threads compressed size=259,153,894 bytes <-- better than in previous 7-zip release(4.65)
LZMA2, 1 thread compressed size=258,168,350 bytes <---- slightly better than LZMA. good!
LZMA2, 3 threads compressed size=258,167,512 bytes <--|
LZMA2, 4 thread compressed size=363,419,965 bytes(>=4 threads gives about the same size)
LZMA, 2 threads compressed size=263,372,021 bytes <-- 7-zip 4.65
lzma2 doesn't split to chunks when you use only 1 or 2 threads.
You can specify chunk size:
-m0c=29
for 4 threads.
>You can specify chunk size:
>-m0c=29
thank You! it will be great, if I can set chunk size for LZMA2 via GUI
fixed: LZMA, 2 threads compressed size=259,153,894<-- same as 9.00