1) That wav24 also has 3 sub-chunks. So next version will support it.
thank you very much
2) I know how to parse PPM. But I'm still not sure that I want to include that code to >> 7-zip now.
please incude that format Igor.. I beg you to do that.
Do you also plan to add more formats later?
Maybe .TIFF, .TGA, .BMP or .PSD or audio formats like .AIFF?
If you think that PE parser in -myx mode works incorrectly, upload some example. Also >> you can open PE files in 7-Zip to check sections and properties.
I am not an expert - just looked inside executables and overlooked the fact that all executables on which your PE parser does not work were VXD executables.
I tested thousands of executables now and cannot find an executable on which it doesn"t work. Please accept my excuses, Igor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) As I remember, the compression ratio gain for RGB data is not so big. So I don't hurry to support them now.
2) Maybe HaoZip just uses calculation:
file_pack_size = block_pack_size / block_unpack_size * file_unpack_size
We need to unpack that solid block to detect real file_pack_size inside solid block.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The PGM/PPM testset is compressed to 363 MB without delta filter
and with delta filter enabled, the archive is 322 MB in size.
The delta filter gives no gain on my 8-bit images like PGM.
In my opinion, the gain for RGB data is big enough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, RAR5 currently is not yet supported as archive format, but it does not prevent the use of free console extractor UnRAR with RarLabs, especially because of its open source.:) unrarw32.exe this SFX archive included binary Win32 version of UnRAR v5.21 and can extract any RAR5 archives. But if you need a GUI wrapper for many file managers have plug-in's allows you to use it.
And while there are more priorities need to be addressed, for example accumulated to this point the error needs to be resolved, and if we now add and support RAR5 it can not only complicate the development, but also greatly increase the number of errors. I believe that we must first eliminate the known bugs, and then you can and move on. Otherwise, new errors will overlap on old and it is very much would delay the development, but in the end decide Igor because he is the author and the last word for it.
Last edit: VictorVG 2015-04-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Igor Pavlov,
It's not a bug, but I wish to report something that is somewhat annoying and that's been present since early versions of 7-Zip.
When I want to select some files inside an archive, I click the first one I need, press the "Shift" key and then click on the last one I need. But the last one is NOT selected! (Please see attached screenshot.)
This is counter-intuitive, since in "Windows Explorer", when we do this, the last file is always selected.
There have been countless times when I think I have extracted all the files, only to later discovered that the last one is missing, which can be very problematic in some situations.
Could you please consider changing this behavior to match Windows Explorer's, so that the last file is also selected?
Thanks you very much for your attention!
And keep up the really nice work!
I was first a little suspicious of the version jump and the release date; but now, almost a week after the release on the 1st of April, there is still no complaint about it being an April Fools joke. So I guess I may try the next one...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's interesting thing.
Actually there is Info-Zip's modification to PkZip's version of ZIP format. And some programs (including WinRAR) probably use that Info-Zip code.
I'll fix the problem in next version of 7-Zip.
Info-Zip modification:
After the header is decrypted, the last 1 or 2 bytes in Buffer
should be the high-order word/byte of the CRC for the file being
decrypted, stored in Intel low-byte/high-byte order, or the high-order
byte of the file time if bit 3 of the general purpose bit flag is set.
Versions of PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
used on versions after 2.0. This can be used to test if the password
supplied is correct or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Console version now uses stderr stream for error
messages.
2) you can check sterr stream instead of stdout or use -bse1 switch to redirect error messages to stdout stream.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Спасибо, Игорь.
Если можно, то хотелось бы увидеть более подробное описание ключей -bb[0-3], -bs[o|e|p][0|1|2], с примерами синтаксиса и значениями этих ключей по умолчанию.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is a missing feature rather than a bug. 7-Zip may call POSIX layer of Win32 API (namely, specifying FILE_FLAG_POSIX_SEMANTICS) to extract such archive correctly on a NTFS-based volume (https://support.microsoft.com/en-us/kb/100625). However, it may ignore the problem since handling of case-only-different filenames is not supported in Win32.
Last edit: Shell 2015-04-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that fat32/ntfs are case insensitive, which is not the problem in this case.
The mayor problem is that 7zipFM crashes when extracting such archives.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi, Igor
thank you new version !
a bug fixed in 9.33 has encountered again in 15.00.
when i fail decompression of password protected .rar file, exit code will to 0.
if the .zip file, exit code will to 2.
I'll fix it. Thanks!
hi, Igor
Thank you for support!
I confirmed this issue is fixed by ver. 15.02 and ver. 15.01.
Thank you!
Dear Igor
Thank you for your answer.
thank you very much
please incude that format Igor.. I beg you to do that.
Do you also plan to add more formats later?
Maybe .TIFF, .TGA, .BMP or .PSD or audio formats like .AIFF?
I am not an expert - just looked inside executables and overlooked the fact that all executables on which your PE parser does not work were VXD executables.
I tested thousands of executables now and cannot find an executable on which it doesn"t work. Please accept my excuses, Igor.
1) As I remember, the compression ratio gain for RGB data is not so big. So I don't hurry to support them now.
2) Maybe HaoZip just uses calculation:
file_pack_size = block_pack_size / block_unpack_size * file_unpack_size
We need to unpack that solid block to detect real file_pack_size inside solid block.
The PGM/PPM testset is compressed to 363 MB without delta filter
and with delta filter enabled, the archive is 322 MB in size.
The delta filter gives no gain on my 8-bit images like PGM.
In my opinion, the gain for RGB data is big enough.
Not working properly with 5.0 rar files.
Yes, RAR5 currently is not yet supported as archive format, but it does not prevent the use of free console extractor UnRAR with RarLabs, especially because of its open source.:) unrarw32.exe this SFX archive included binary Win32 version of UnRAR v5.21 and can extract any RAR5 archives. But if you need a GUI wrapper for many file managers have plug-in's allows you to use it.
And while there are more priorities need to be addressed, for example accumulated to this point the error needs to be resolved, and if we now add and support RAR5 it can not only complicate the development, but also greatly increase the number of errors. I believe that we must first eliminate the known bugs, and then you can and move on. Otherwise, new errors will overlap on old and it is very much would delay the development, but in the end decide Igor because he is the author and the last word for it.
Last edit: VictorVG 2015-04-06
Dear Igor Pavlov,
It's not a bug, but I wish to report something that is somewhat annoying and that's been present since early versions of 7-Zip.
When I want to select some files inside an archive, I click the first one I need, press the "Shift" key and then click on the last one I need.
But the last one is NOT selected!
(Please see attached screenshot.)
This is counter-intuitive, since in "Windows Explorer", when we do this, the last file is always selected.
There have been countless times when I think I have extracted all the files, only to later discovered that the last one is missing, which can be very problematic in some situations.
Could you please consider changing this behavior to match Windows Explorer's, so that the last file is also selected?
Thanks you very much for your attention!
And keep up the really nice work!
Yes, it's BUG.
If "Show .. item" mode is enabled, it doesn't select last item.
I'll fix it in next version. Thanks!
I was first a little suspicious of the version jump and the release date; but now, almost a week after the release on the 1st of April, there is still no complaint about it being an April Fools joke. So I guess I may try the next one...
не открывает файл rsload.net.6.23.10.zip http://rsload.net/noload/files/059/rsload.net.Internet.Download.Manager.6.23.Build.10.zip с правильным паролем, пишет wrong password, а winrar открывает с тем же паролем, пароль на архив rsload.net
It's interesting thing.
Actually there is Info-Zip's modification to PkZip's version of ZIP format. And some programs (including WinRAR) probably use that Info-Zip code.
I'll fix the problem in next version of 7-Zip.
Info-Zip modification:
Hi, am testing now, I'm just wondering if this has support for wavpack? Ive tested with a few different wavs and they just get compressed normally.
Many thanks
Тестирую запароленный 7zSFX такой строкой:
7z l -slt -p1111 test.exe
(пароль указан заведомо неверный)
В батнике получаю следующий вывод:
7-Zip [64] 15.00 alpha : Copyright (c) 1999-2015 Igor Pavlov : 2015-04-01
Scanning the drive for archives:
1 file, 637561 bytes (623 KiB)
Listing archive: test.exe
ERROR: test.exe : Can not open encrypted archive. Wrong password?
ERRORS:
Headers Error
Errors: 1
s:>
7-Zip [64] 9.38 beta Copyright (c) 1999-2014 Igor Pavlov 2015-01-03
Error: test.exe: Can not open encrypted archive. Wrong password?
Errors:
Headers Error
Errors: 1
s:>
В AutoIt скрипте перенаправляю вывод в лог и получаю следующий вывод:
7-Zip [64] 15.00 alpha : Copyright (c) 1999-2015 Igor Pavlov : 2015-04-01
Scanning the drive for archives:
1 file, 637561 bytes (623 KiB)
Listing archive: s:\test.exe
Errors: 1
7-Zip [64] 9.38 beta Copyright (c) 1999-2014 Igor Pavlov 2015-01-03
Error: s:\test.exe: Can not open encrypted archive. Wrong password?
Errors:
Headers Error
Errors: 1
В выводе последней версии отсутствует строка:
Can not open encrypted archive. Wrong password?
по которой скрипт определял запароленность архива.
Почему пропала эта строка и можно ли ее вернуть?
1) Console version now uses stderr stream for error
messages.
2) you can check sterr stream instead of stdout or use -bse1 switch to redirect error messages to stdout stream.
Спасибо, Игорь.
Если можно, то хотелось бы увидеть более подробное описание ключей -bb[0-3], -bs[o|e|p][0|1|2], с примерами синтаксиса и значениями этих ключей по умолчанию.
При распаковке запароленного 7zSFX строкой:
7z x test.exe
в окне консоли ввожу пароль (заведомо неверный)
Код возврата версии 15.0 = 0
Код возврата версии 9.38 = 2
Можно ли это исправить, т.к. 2 - более соответствует ситуации (пароль неверный, архив не извлечен)
There was report about similar problem in this thread.
I've fixed that problem for 15.01.
Found a bug (appears to be in the latest stable as well), when extracting some archives the "Confirm File Replace" dialog is unusable.
For example: https://www.fyn.nl/veloconnect_1_1.tgz (this can occur in zip files as well)
This can occur when using a case insensitive filesystem with archives created on a case sensitive file system.
Last edit: Michiel Hazelhof 2015-04-13
I think this is a missing feature rather than a bug. 7-Zip may call POSIX layer of Win32 API (namely, specifying
FILE_FLAG_POSIX_SEMANTICS) to extract such archive correctly on a NTFS-based volume (https://support.microsoft.com/en-us/kb/100625). However, it may ignore the problem since handling of case-only-different filenames is not supported in Win32.Last edit: Shell 2015-04-13
I understand that fat32/ntfs are case insensitive, which is not the problem in this case.
The mayor problem is that 7zipFM crashes when extracting such archives.
No crash on my 7-Zip 15.00 (Vista x86 SP2). What is your version?
7-Zip 15.00 alpha [64-bit] (8.1 X64), as soon as the overwrite dialog pops up the interface becomes unresponsive.
OK, then it is really a bug, and this bug seems to be OS-specific.