» WinRAR (часть 2)

Ребята, скажите, а в Total Commander Unrar.dll и Unrar64.dll в чистом виде как у Евгения?
То есть можно просто заменить на более новую?

lelik007
Да, в чистом виде, для обновления просто кидается свежая .dll в корневой каталог TC с заменой, и он ее без проблем подхватывает после перезапуска.

SergikZ
а еще лучше, чтоб не плодить файлы, делать симлинки. например этим Link Shell Extension
наделать линков. а потом просто в одном месте обновлять этот файл.

EugeneRoshal
Евгений, а вы не подскажите, по какому вы принципу отбираете "стабильные версии" 7zxa.dll? Просто только у Вас я увидел версию 9.38. В поставке Bandizip и TotalCommander - релиз, то есть 9.20. Может вы что то знаете...

Цитата:

привет, а дизайн архиватора будете обновлять? если да то когда? а то уже старый уж очень-очень давно и приелся, а отдельные кривые темы от пользователей не хочется!

Ничего ты не понимаешь , олдскульный дизайн рара это же "дух времени" целой эпохи.
Да и плюс он очень удобен для быстрой ориентации, а сидеть разглядывать красивые менюшки с фаньтиками ищя нужную функцию, как в новом офисе это УГ.

lelik007

Цитата:

Евгений, а вы не подскажите, по какому вы принципу отбираете "стабильные версии" 7zxa.dll? Просто только у Вас я увидел версию 9.38. В поставке Bandizip и TotalCommander - релиз, то есть 9.20.

Какой-то специальной системы тут нет. Просто решил проверить обновления, нашел новую версию dll, потестировал, проблем не обнаружил, включил в очередную бету WinRAR. После этого про обновление этой dll на какое-то время можно забыть.

А 9.20 ведь уже больше четырех лет. За это время наверняка немало ошибок было исправлено. Так что большой вопрос - надежнее ли тот релиз этой беты 7zxa.dll.

Не докачался архив с музыкой.
757 мб вместо 817 мб.
А первая часть на 900мб.



Не распаковывается.
Абидна ведь 10 часов качалось.
Можно ли распаковать что есть?

Русская бета 2
x86:
http://www.rarlab.com/rar/wrar530b2ru.exe
x64:
http://www.rarlab.com/rar/winrar-x64-530b2ru.exe

Veselozhopy
Если там несколько файлов, то сделай распаковку всего архива. Выдели в проводнике первую часть, ПКМ, WinRAR->Извлечь файлы...
Если там один файл или нужен последний путь даже битый, то поставь галку "Не удалять файлы извлеченные с ошибками".

Цитата:

Выдели в проводнике первую часть, ПКМ, WinRAR->Извлечь файлы...
Если там один файл или нужен последний путь даже битый, то поставь галку "Не удалять файлы извлеченные с ошибками".

Ок. СПС

Цитата:

Русская бета 2

Цитата:

1. SFX-модуль устанавливает переменную окружения sfxstime, содержащую
время запуска модуля в формате "ГГГГ-ММ-ДД-ЧЧ-ММ-СС-мс".
Её можно указывать в команде Path, если требуется генерировать
уникальный путь установки ПО на основе времени, например
"Path=myapp-%sfxstime%".

2. Уменьшено количество запросов командой преобразования архивов
в следующих случаях:

а) если команда "Преобразовать архивы" применяется к архиву
с зашифрованными именами файлов, содержимое которого в данный момент
отображается в WinRAR;

б) если архив, созданный командой "Преобразовать архивы", включает
зашифрованные имена файлов.

3. Исправлены ошибки:

а) RAR-тома, переименованные из стандартных .part1.rar, .part2.rar в
.001, .002, теперь распознаются и обрабатываются правильно.
Предыдущая бета-версия открывала их как набор обычных разделённых
на части файлов, а не томов RAR;

б) отчёты, созданные командой "Создать отчёт", содержали неверные
контрольные суммы для файлов не в архивах;

в) команда "rar x arcname.rar d:" распаковывает файлы в текущую папку
на диске d:. Предыдущая бета-версия распаковывала их в корневую
папку диска d:;

г) комментарий архива не зашифровывался, если он добавлялся в архив
с зашифрованными заголовками командой "c" без указания ключа -hp.
Данная бета-версия в этом случае зашифровывает архивный комментарий.

EugeneRoshal
Я понял Евгений, просто у Игоря бета 15.05 последняя, наверное на момент тестирования,
не было ее еще. А вообще я ему предлагал не плодить фичи, а отработать хорошо, что есть, вот как вы делаете и выпустить наконец релиз. Чтобы другие авторы и разработчики на него могли ориентироваться. А то все ориентируются на релиз 4-х летней давности. Но просьбу Игорь отклонил.

EugeneRoshal, скажите пожалуйста, сколько примерно ещё будет бета-версий, и когда планируется выйти финальная версия винрара?

Dmitriandr
Пока что бета-тестирование 5.30 идет меньше месяца, а желательно хотя бы месяца 2 - 3. Так что как минимум beta 3 еще будет, а дальше - в зависимости от найденных ошибок. Если в очередной бете ничего серьезного не обнаружится, можно думать о релизе.

EugeneRoshal
Имеется zip-архив сжатый методом Deflate64 и зашифрованный AES-256. Winrar его открывает, нормально тестирует, но в созданном текстовом отчёте по этому архиву показывает CRC для всех файлов в архиве равное 00000000.
Это нормально или я что-то не так сделал?

Vorland
А если открыть архив в оболочке WinRAR, там в колонке CRC32 тоже нули? Может у этих файлов действительно CRC32 равно нулю. Иногда содержимое файлов подгоняют под желаемое значение CRC32.

EugeneRoshal

Цитата:

А если открыть архив в оболочке WinRAR, там в колонке CRC32 тоже нули?

Открыл, посмотрел - тоже нули. Посмотрел, что пишет WinRar в информации о архиве: версия для извлечения: 2.1/m99

Ради интереса открыл этот архив в 7-zip - так там колонка CRC вообще пустая для всех файлов.

Интересный какой-то архив. Может быть это всё из-за шифрования? И можно ли доверять команде тестирования целостности такого архива в WinRar?

P.S. Архив создан программой для бэкапа "SyncBack SE"

Vorland

Цитата:

И можно ли доверять команде тестирования целостности такого архива в WinRar?

P.S. Архив создан программой для бэкапа "SyncBack SE"

Упакуйте какой-нибудь небольшой файл этой программой так, чтобы и у него был CRC32 0, пришлите мне его на dev@rarlab.com вместе с паролем к архиву. Я посмотрю, в чем там дело.

Vorland

У неё может быть иной механизм проверки целостности. Например по SHA-256/384/512. Дольше чем CRC, да, зато надёжно. Кстати на UNIX CRC-хх давно для проверки целостности не используется. Годика эдак с 70-го. Единственное место где её применение оправдано это сигнатурный анализ для диагностики железа - на вход исследуемого узла подаётся созданная специально для него тест-последовательность, выходной поток делится на полином CRC-15, остаток сохраняется в регистре и после сравнивается результат двух последовательных прогонов теста. Если хранящиеся в сдвиговом регистре прибора данные не совпадают то узел не исправен и прибор зажигает лампочку ошибки "НЕСТАБИЛЬНОСТЬ". У самого такой прибор есть и работает ещё с 80-го года - микросхемы 155ИР3 штука дубовая сжечь трудно, а коли сгорят иди найди им замену - их уже лет двадцать не выпускают.

Victor_VG
Цитата:

У неё может быть иной механизм проверки целостности. Например по SHA-256/384/512. Дольше чем CRC, да, зато надёжно. Кстати на UNIX CRC-хх давно для проверки целостности не используется. Годика эдак с 70-го.

Не путай проверку целостности и другие виды использования контрольных сумм.
Для проверки нормальный файл или испорчен CRC-32 вполне хватает. Если кому-то не хватает, то можно MD5 использовать. Всякие SHA-256 и т.п. это уже перебор.

V0lt

Тут ты не прав потому, что CRC-хх, MD4/MD5 дадут ошибку сравнения пары файлов с очень высокой вероятностью (для MD5 вероятность ошибки 0,00027), но для ловли факта НЕСТАБИЛЬНОСТЬ ПАРЫ ПОСЛЕДОВАТЕЛЬНЫХ ИЗМЕРЕНИЙ CRC-15/16/32 годится.

Для алгоритмов семейства SHA1 (SHA1, торрент хэш) вероятность ошибки несколько ниже (примерно на порядок), но существует и главное экспериментально доказан ещё в 2003-м году, а значит данные алгоритмы давно скомпрометированы, в то время для семейств SHA2 и SHA3 (SHA-256/384/512, SHA3-256/384/512) пока факт коллизии алгоритма не установлен.

Возникновение ошибки CRC-хх обусловлено самой природой его хэш-функции как свёртки от деления входного потока на полином с кодовым расстоянием N и даже если увеличить его длину она не сильно снизится оставаясь в пределах > 0,001 (> 0,1%), так что для проверки целостности они не применимы, только для проверки факта были ли какие-то изменения входного потока, да и то они не всегда их обнаружат т.к. не принципиально способны обнаруживать ошибки кратностью выше N.

Примером ограниченных по степени обнаружения ошибок алгоритмов может служить код Хемминга использующий сравнение вычисленной с помощью mod2(a,b) диагональной матрицы блока с единичной - алгоритм считает что блок не изменился если в результате нескольких циклов итераций получена единичная матрица, но если число ошибок в блоке превысит его кодовое расстояние он может их не обнаружить. Если число ошибок меньше кодового расстояния алгоритма он может их исправить за N итераций, но это снизит быстродействие использующего его устройства. Именно код Хемминга применяется в ЕСС памяти, но там обычно исходят из того, что вероятность кратных ошибок в блоке значительно ниже чем вероятность инверсии значения (ошибки) одной ячейки, а потому обычно правят только одиночные ошибки. В СССР для этого выпускалась микросхема 1804ВЖ1 16-и битного контроллера кода Хемминга (входила в секционированный 4-х битного МПК 1804 аналог AMD Am2900) сам в 80-х на ней контроллер сети проектировал.

Victor_VG
Цитата:

Тут ты не прав потому, что CRC-хх, MD4/MD5 дадут ошибку сравнения пары файлов с очень высокой вероятностью

Я говорил про проверку целостности, а не сравнение файлов. MD5 там выше крыши.


Цитата:

Для алгоритмов семейства SHA1 (SHA1, торрент хэш) вероятность ошибки несколько ниже (примерно на порядок), но существует и главное экспериментально доказан ещё в 2003-м году, а значит данные алгоритмы давно скомпрометированы, в то время для семейств SHA2 и SHA3 (SHA-256/384/512, SHA3-256/384/512) пока факт коллизии алгоритма не установлен.

Я могу тебе с 100% точностью сказать, что на любом из описанных тобою хэшах возможны коллизии. Даже доказательство могу озвучить.

Victor_VG
V0lt
Вы говорите о разных вещах, созданных и применяемых для разных целей - обычной чексумме (CRCxx) и криптографически стойком хэш-алгоритме (SHA-2/SHA-3).

Vorland

Цитата:

Интересный какой-то архив. Может быть это всё из-за шифрования? И можно ли доверять команде тестирования целостности такого архива в WinRar?

Вот поэтому давно стоит перейти на формат RAR5 со включенным вместо crc32 алгоритмом Blake2.

V0lt
Victor_VG
MD5 крайне редко коллизии дает на практике, никто из тех кто этим специально занимались,
кого я знаю не видели их. Даже на массиве из 1 миллиона файлов. Если криптостойкости не нужно,
вполне годная хеш-функция проверки целостности. Лично я ее считаю достаточно коллизионно-стойкой.

Я как то применял CRC32+Adler32, либо CRC32+xxHash - коллизии CRC32 я сам видел,
поэтому использую небольшую быструю общую хеш-функцию, дублер. Связки там быстрее работали,
чем MD5 (не помню что за железо).

А криптографические хеш-функции для проверки целостности - Whirlpool можно применить, только зачем, если именно нужна простая контрольная сумма без коллизий, для отслеживание изменений.

Хотя нужно сказать что высокая устойчивость к коллизиям одна из основных характеристик криптографической хеш-функции,
т.к. на хеш ими сделанный ставят ЦП и используют для шифрования паролей. А ну как вот хеш совпадет, нехорошо будет. Да и размер хеша,
побольше. Что такое сейчас 32 бита хеш. Смех.

Vorland
Я посмотрел на ваш архив, это ZIP AES в модификации AE-2. В ней CRC32 отсутствует, а контроль целостности данных выполняется с помощью проверочного кода, хранящегося после зашифрованных данных файла. При распаковке и тестировании WinRAR проверяет этот код.

Я сейчас выложил новую сборку английского WinRAR 5.30 beta 2, которая для таких архивов CRC не показывает совсем. Чтобы не сбивать с толку пользователей нулями.

EugeneRoshal
Евгений, скажите, а GPGPU никак в задачах архивации не применить в том случае, если процессор так себе,
а например видео-карта мощная?

lelik007
Я не знаю, как это эффективно сделать для RAR'овских алгоритмов.

EugeneRoshal

Цитата:

Я сейчас выложил новую сборку английского WinRAR 5.30 beta 2, которая для таких архивов CRC не показывает совсем. Чтобы не сбивать с толку пользователей нулями.

Спасибо Вам, но как мне кажется, отсутствие CRC не менее собьёт пользователя с толку...

Может быть для таких архивов можно было бы менять заголовок колонки с "CRC32" на, например, "Проверочный код", и выводить эти коды для каждого файла ?

Кстати, просто для информации, это проверочные коды насколько надёжны для контроля целостности файлов в архиве?

EugeneRoshal
Евгений, так дело же в том, что там и должны быть нули, вернее 0, по спецификациям самого WinZip:
Или будет храниться, но не отображаться? А что сам WinZip там делает? Показывает это поле пустым или одни нули?
А вот это HMAC-SHA-1 что они написали, как код аутентификации он вообще то показывает, для архивов AE-2?

Цитата:

CRC value
For files encrypted using the AE-2 method, the standard Zip CRC value is not used, and a 0 must be stored in this field. Corruption of encrypted data within a Zip file is instead detected via the authentication code field.
Files encrypted using the AE-1 method do include the standard Zip CRC value. This, along with the fact that the vendor version stored in the AES extra data field is 0x0001 for AE-1 and 0x0002 for AE-2, is the only difference between the AE-1 and AE-2 formats.

Vorland
На столько:
http://www.winzip.com/aes_info.htm#authentication-code
и настолько http://www.winzip.com/aes_info.htm#auth-faq

lelik007
Цитата:

так дело же в том, что там и должны быть нули, вернее 0, по спецификациям самого WinZip

Это внутри самого архива пишут 0, если CRC-32 не используется, просто чтобы хоть что-то в свободное поле записать. Его незачем показывать, т.к. он не соответствует реальному CRC-32 для файла в архиве.