Moderators: Hacker, petermad, Stefan2, white
Please, check your facts before you comment - it has (from 7z's readme.txt):herman5 wrote:(apart from the fact that its a bad packer wich doesnt even has an unpack only library...)
The first one is 269KB and the the other 170KB.7za.dll - library for working with 7z archives.
7zxa.dll - library for extracting from 7z archives.
I did the convert archive option from a zip to a zip to improve compression, it was a medium size archive about ten Megabytes I got it from a friend, it was a zip of jpg's I know jpg's don't compress as they're already compressed but you can squeeze some bytes from the exif, the conversion completed there was no error report but then when I tried opening the zip two files ware damaged there was no crc for it stored winrar reported it as 0000, I re-downloaded the zip and didn't re-compress it, I removed the beta as it looked a lot slower when packing to zip compared with 4.11 (I noticed the same speed regression in 4.20)Can you please provide me more information about these archives: which options did you use, how concretely they are broken (checksum error or something else). If you can send me original files used to create these archives, it can help me to reproduce and fix this bug.
Anyway, if you consider security in file archiving, 7-Zip stil have unresolved bug involving "Encrypt file name" enabled option. This bug is more than two years old if you take bug report into account.Alextp wrote:WR5 looses!! to 7Zip. in all 3 tests. Hmm
Nobody take this into consideration when testing WinRAR and 7-Zip, at least I've not seen it."An archive created with password protection and file name encryption option enabled will lose file name encryption and password protection if a new file is added. "
