![]() If you want to help then ask those guys if they can provide the proof of data corruption. WinRar checks for CRC stored inside the 7z and will report if something went wrong so I can't imagine scenario when WinRar extracts corrupted data.īut shit happens sometimes. WinRar x86 versions with LZMA2 support immediately report Not enough memory so there is no data loss because no data unpackedĤ. WinRar 圆4 versions with LZMA2 support (at least tested 4.20, 5.31, 6.21) are able to decompress 7z archives with LZMA2:1536mģ. ![]() The archives are usual 7z archives, created with LZMA2:1536m methodĢ. I think its only the difference in memory allocation methods maybe.ġ. Interesting thing is that 7-zip 32bit is able to unpack those files so maybe its a good idea to report it to WinRar author.īut I repeat: we do not talk about some fault here. Not enough memory message immediately thrown so I think there is no chance of loosing data even for 32bit versions because no data is unpacked with it. Unfortunately 32bit versions of WinRar I tested (4.20, 5.31, 6.21) cannot handle such archives. It was able to decompress all files correctly too. WinRar 4.20 圆4 (7zxa.dll 9.22 beta) and you know what? I unpacked both 7z files with 7-zip 21.00 alpha 圆4 and WinRar 5.31 圆4 (7zxa.dll 15.09 beta) to different folders and compared using Total Commander Synchronize directories function.Īlso there is checksums.md5 file in Tools subfolder and I checked that all files are correct with it.īut the question is: what will happen if you'll use WinRar which is supplied with some pre-15.x version of 7zxa.dll ? The dictionary size of 1536m became available in 7-zip 15.05 beta () and since this is the first 15.x version mentioned in history.txt, then any product based on 7zxa.dll 15.x and later should handle such archives correctly.Īctually any product with LZMA2 support and which happen to successfully allocate large memory blocks should handle such archives correctly. WinRar known for its emphasis towards security and stability for many years and I can't believe that loss of data during 7z extraction have gone unnoticed and unfixed.īut there is one thing that must be noted.Īctually WinRar handles 7z archives via native 7zxa.dll which is the part of 7-zip Extra package.Īrchives you provided are simple 7z archives with LZMA2:1536m and 2 solid blocks. We suspect that Pavlov's choice of LGPL, rather than full GPL, may be because 7-Zip includes the unRAR library so that it can unpack files in the proprietary RAR format.Birdie is right and I also think that such claims about WinRar's potential problems are nothing more than crap. ![]() The counter-evidence that it's possible is that there is at least one fork of 7-Zip out there: NanaZip, which claims better Windows 10/11 integration. The author has used Git professionally for many years, cordially loathes it, and strongly suspects he is not alone in this.Īs evidence of the difficulty of building 7-Zip from source, "Paul" links to a discussion from 2010. 7-Zip has a single author, Igor Pavlov, and if he doesn't want to use Git, The Reg FOSS desk doesn't blame him. Git's a complicated tool, which is why Linus Torvalds gave it the name: it's British English for a hostile or uncooperative person. There is no need to use Git source code management if you don't need it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |