Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 4)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

Открыть новую тему     Написать ответ в эту тему

Maz



Дед Мазай
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
По вопросам лечения (кряки, патчи и т.д.), а также разблокировки архивов, обращаемся в «Варезник».
Отдельная тема по сборкам WinRAR
Предыдущие части темы: Часть 1 | Часть 2 | Часть 3



Официальный русский сайт: win-rar.com
Официальный e-mail разработчика WinRAR (писать на русском): dev@rarlab.com
 
Финальная английская версия: 6.02 x86 | x64 (14.06.2021)
Финальная русская версия:  6.02 x86 | x64 (14.06.2021)

Текущая английская бета-версия:  6.10 beta 1 x86 | x64
Текущая русская бета-версия:  6.10 beta 1 x86 | x64
Примечание: английская бета-версия обновляется регулярно, без изменения номера версии. подробнее...
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

 
Скачать ранее вышедшие версии также можно с официального сайта и win-rar.com.

Версия 3.62 (ru) с подарочным ключом (респект камраду elmorte)

Коллекция всех ранее выходивших версий WinRAR 1.54b - 6.00 (1995-2020): скачать (265 МБ) [обновлено 10.01.2021]

вместо F.A.Q. || альтернативные архиваторы

Почему опять задерживается русская версия? А при русском разработчике на языке XXX уже давно есть. Не захламляйте тему подобными вопросами.

Кому не нравится новая тема оформления - скачайте с официального сайта rarlab.com (из раздела Themes) и установите себе WinRAR Classic theme by Francesco Indrio: Стандартная (48x36). Мелкие кнопки (24x24)

В теме активно отвечает на вопросы автор архиватора Евгений Рошал! Ситуация уникальная, прошу пользоваться.

Всего записей: 37447 | Зарегистр. 26-02-2002 | Отправлено: 19:30 27-08-2020 | Исправлено: DimmY, 21:28 10-10-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Vorland

Цитата:
сброс кешей перед проверкой

Я подумаю на этот счет в 6.1.
Пока я готовлю 6.01 с исправлением ошибок, но без новых функций.
 
Правда предложенный метод сброса кэша недокументирован и теоретически может перестать работать в следующих Windows. Но документированных способов для отдельных файлов, похоже, нет.

Цитата:
возможно, было бы неплохо сделать опционально бинарное сравнение файлов тестируемого архива с исходными на диске

По ходу упаковки файлы на диске могут меняться. Особенно если это какой-нибудь большой бэкап на несколько часов. В итоге получим массу сообщений о несовпадающих данных, которые не прояснят причину такого несовпадения. То ли архив битый, то ли совершенно штатно поменялся файл на диске.

Цитата:
т.к. не стоит забывать про коллизии хешей

Если выбрать Blake2, вероятность коллизий становится пренебрежимо мала.
 
GoblinNN

Цитата:
в winrar 7 будет blake3?

Я всерьез его рассматривал, но на мой взгляд он оказался слишком тяжеловесным для хэша архиватора. Насколько я помню, там объем исходников раза в 2 - 3 больше, чем у Blake2, который уже довольно немаленький для архиваторного хэша - 11 кб C кода, если без SIMD.
 
В прошлый раз мне не удалось существенно уменьшить размер кода Blake3. Может когда попробую опять.
 
Кроме того, разработчики в качестве основного языка перешли на Rust. Версия на C имеется, но многопоточность в ней предлагается добавить самостоятельно.

Цитата:
в андроид версии rar есть инструмент подсчета контрольных сумм

Судя по обратной связи, это одна из наименее используемых функций RAR. Так что сейчас я не планирую ни ее доработок, ни переноса в WinRAR.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 11:44 10-02-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
los
 
Штатная для UNIX появившаяся в AT&T UNIX в 70 году, более того, этот же формат записи хэша используется в IBM OS/390, но та понимает и BSD запись, а вот без звёздочки воспринимает как ошибку записи.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2667/C602J/16 GB REG ECC DDR3-1866/GTX 1660, i7-2600/z68/16 Gb DDR3-1600/GTX 1060 3Gb

Всего записей: 29434 | Зарегистр. 31-07-2002 | Отправлено: 14:50 10-02-2021
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal

Цитата:
Правда предложенный метод сброса кэша недокументирован и теоретически может перестать работать в следующих Windows. Но документированных способов для отдельных файлов, похоже, нет

Заодно полезно выяснить - как это скажется на общей скорости.
 

Цитата:
В прошлый раз мне не удалось существенно уменьшить размер кода Blake3. Может когда попробую опять.

Если только при очередном изменении формата. Более старые версии этот хэш всё равно "не знают".

Всего записей: 6666 | Зарегистр. 01-10-2002 | Отправлено: 16:15 10-02-2021
insorg



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Та пока и второго - за глаза.

Всего записей: 1972 | Зарегистр. 04-11-2010 | Отправлено: 16:23 10-02-2021
los

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
xxHash в качестве замены не рассматривали? Он весьма шустрый хотя меня и blake2 устраивает.
 
Victor_VG

Цитата:
Штатная для UNIX появившаяся в AT&T UNIX в 70 году...

смешались в кучу кони, люди...

Всего записей: 4640 | Зарегистр. 08-09-2001 | Отправлено: 16:54 10-02-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Benchmark

Цитата:
Заодно полезно выяснить - как это скажется на общей скорости.  

Снизит, конечно, так как данные будут браться с диска, а не кэша. Но позволит выявить ошибки обмена с диском. Если дойдет дело до реализации, посмотрю на производительность более предметно.

Цитата:
Если только при очередном изменении формата. Более старые версии этот хэш всё равно "не знают".

На переходный период, вероятно, можно было бы хранить для файла и CRC32, и новый хэш. Потом, даже если хэш неизвестен, старые версии такой архив распакуют без проверки целостности. Но мне не нравится объем C++ Blake3 кода. Для сравнения, у меня исходники SHA-256 занимают 4кб, slicing-by-8 CRC32 - 2кб.
 
los

Цитата:
xxHash в качестве замены не рассматривали? Он весьма шустрый хотя меня и blake2 устраивает.

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

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 17:39 10-02-2021
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal

Цитата:
Потом, даже если хэш неизвестен, старые версии такой архив распакуют без проверки целостности

Это очень плохо.
 
Тогда вопрос более общий: является ли подчсёт blake2 "бутылочным горлышком" в плане производительности ? Ну т.е. есть ли вообще смысл заморачиваться по поводу очередной смены хэш-алгоритма ?

Всего записей: 6666 | Зарегистр. 01-10-2002 | Отправлено: 19:21 10-02-2021
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Benchmark
BLAKE2s в один поток на i5-6600 считает 650 МБ/с (тест на офсайте). Версия sp - 8-поточная. При наличии многопоточного процессора или при использования SSE скорость может вырасти в разы.
С учетом того, что B2sp используется только в RAR5 - существенного вклада расчет не вносит.

Всего записей: 10085 | Зарегистр. 11-03-2002 | Отправлено: 19:51 10-02-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Benchmark

Цитата:
Это очень плохо.

Запретить распаковывать такие файлы старым версиям тоже можно. Но не факт, что это лучше, чем разрешить без контроля хэша.

Цитата:
Тогда вопрос более общий: является ли подчсёт blake2 "бутылочным горлышком" в плане производительности ?

Разве что на малопоточном ARM, да и там разница с CRC32 будет сколько-нибудь заметна скорее в режиме -m0. При 8+ потоках на x86 скорость где-то на уровне CRC32.

Цитата:
Ну т.е. есть ли вообще смысл заморачиваться по поводу очередной смены хэш-алгоритма ?

Был бы он покомпактнее, я бы еще подумал. Быстрый криптографический хэш, масштабируемый на любое количество потоков, это интересно. А сейчас я особо и не заморачиваюсь.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 19:51 10-02-2021
ewild

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Запретить распаковывать такие файлы старым версиям тоже можно. Но не факт, что это лучше, чем разрешить без контроля хэша.

Можно сделать и не нашим, и не вашим, если реализуемо, - явно информировать пользователя и далее по явному же выбору последнего (в real-time или по устанавливаемой опции) с пониманием распаковать без контроля хэша, либо отказаться от такого действия.

Всего записей: 1087 | Зарегистр. 13-08-2005 | Отправлено: 11:55 11-02-2021
fonaskin



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Интересно, сколько вообще людей используют BLAKE2 в своих архивах? Вероятность повреждения архива, которое не будет выявлено CRC32, стремится к нулю. Не так ли?

Всего записей: 31 | Зарегистр. 23-11-2017 | Отправлено: 17:07 11-02-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
fonaskin
Конечно, область применения BLAKE2 не очень широка, но она есть. Например, для поиска файла по содержимому, в частности - для поиска дубликатов. При совпадении CRC32 для достоверного определения дубликата надо обязательно выполнять побайтовое сравнение, а для BLAKE2 вероятность коллизии весьма мала, поэтому побайтовой проверкой можно (по желанию пользователя) пренебречь.
 
Кстати, вопрос для EugeneRoshal: опция -oi работает при добавлении файла в архив, в котором есть побайтовая копия добавляемого файла? Если нет, то можно её реализовать как раз через проверку размера и хэша.

Всего записей: 490 | Зарегистр. 12-06-2019 | Отправлено: 20:02 11-02-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell

Цитата:
опция -oi работает при добавлении файла в архив, в котором есть побайтовая копия добавляемого файла?

Нет.

Цитата:
Если нет, то можно её реализовать как раз через проверку размера и хэша.

Для Blake2 это, по идее, реализуемо. Для CRC32 - нет.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 20:12 11-02-2021
los

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
fonaskin

Цитата:
Интересно, сколько вообще людей используют BLAKE2 в своих архивах? Вероятность повреждения архива, которое не будет выявлено CRC32, стремится к нулю. Не так ли?

где-то так и есть Не уверен что большинство пользователей вообще знает о наличии blake2 в программе, а уж тем более его активно использует.

Всего записей: 4640 | Зарегистр. 08-09-2001 | Отправлено: 20:13 11-02-2021 | Исправлено: los, 20:14 11-02-2021
Rezonance



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Victor_VG, спасибо за идею.
Fenrizz, спасибо за реализацию)

Цитата:

Код:
cmd=cmd /k ""%commander_path%\Programm\WinRarC\Rar_x64.exe"  
param=t %N"


Код:
cmd=cmd /c ""%commander_path%\Programm\WinRarC\Rar_x64.exe"  
param=t %N & pause"

Способ универсальный! Глобальное решение незакрытия окна консоли найдено! Особенно cmd /c очень помог, и не только в данном случае...

Всего записей: 3 | Зарегистр. 07-09-2009 | Отправлено: 21:39 11-02-2021 | Исправлено: Rezonance, 13:51 12-02-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
los
fonaskin
 
Алгоритмы семейства CRC ловят ошибки простым делением потока на образующий полином вида f (x) (x+1)F(x) с последующим сравнением остатков текущего и предыдущего шагов тестирования для выявления ошибок нестабильности остатка.  
 
Пример использования данного метода:

Цитата:
СИГНАТУРНЫЙ АНАЛИЗАТОР
    ИВАНОВ МИХАИЛ АЛЕКСАНДРОВИЧ
Тип: авторское свидетельство
Номер свидетельства: SU 1247876 A1 Патентное ведомство: СССР
Год публикации: 1986
Номер заявки: 3843818
Дата регистрации: 17.01.1985
Дата публикации: 30.07.1986
Заявитель:  МОСКОВСКИЙ ОРДЕНА ТРУДОВОГО КРАСНОГО ЗНАМЕНИ ИНЖЕНЕРНО-ФИЗИЧЕСКИЙ ИНСТИТУТ

но его принципиальными недостатками являются необходимость трудоёмкой предварительной подготовки диагностических наборов под конкретную аппаратуру и невозможность однопроходного обнаружения ошибок. Потому сегодня его применение в ВТ ограничено, несмотря на высокое быстродействие данного метода.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2667/C602J/16 GB REG ECC DDR3-1866/GTX 1660, i7-2600/z68/16 Gb DDR3-1600/GTX 1060 3Gb

Всего записей: 29434 | Зарегистр. 31-07-2002 | Отправлено: 22:43 11-02-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Victor_VG
К сожалению, РИНЦ, на который Вы ссылаетесь, фильтрует IP-адреса и не всем желающим даёт доступ. Но ссылка на авторское свидетельство интересная, спасибо.

Всего записей: 490 | Зарегистр. 12-06-2019 | Отправлено: 10:44 12-02-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
 
Не вопрос - вот скриншот описания изобретения:
 

 
кстати ещё до подачи этой заявки в советских токарных станках с ЧПУ 16К3 (я их видел в 83-м году) использовалась диагностическая плата сигнатурного анализатора СА-3 проверявшая работоспособность управляющей ЭВМ НЦ-31 и её обвески.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2667/C602J/16 GB REG ECC DDR3-1866/GTX 1660, i7-2600/z68/16 Gb DDR3-1600/GTX 1060 3Gb

Всего записей: 29434 | Зарегистр. 31-07-2002 | Отправлено: 14:26 12-02-2021
Vorland

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal

Цитата:
Цитата:
возможно, было бы неплохо сделать опционально бинарное сравнение файлов тестируемого архива с исходными на диске


Цитата:
По ходу упаковки файлы на диске могут меняться. Особенно если это какой-нибудь большой бэкап на несколько часов. В итоге получим массу сообщений о несовпадающих данных, которые не прояснят причину такого несовпадения. То ли архив битый, то ли совершенно штатно поменялся файл на диске.  

А если сделать эту опцию по-умолчанию выключенной? Чтобы только понимающие суть пользователи её включали и были бы "сами себе злобными Буратино"?
Blake я и так использую по-умолчанию для своих архивов, но хотелось бы повысить уверенность в целостности данных через сравнение.

Всего записей: 96 | Зарегистр. 20-12-2005 | Отправлено: 13:46 17-02-2021
insorg



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Vorland
Тогда с этим уже не к архиватору, а прямиком к Total Commander с функцией синхронизации и сравнения по содержимому. Для конкретно RAR архивов участвуют всё тот же WinRAR.exe/RAR.exe для создания архива, и всё тот же каноничный unRAR.dll без всяческой отсебятины.
Хотя, в целом была бы очень полезна фича именно прямого сравнения файлов побайтово, а не только через хеши.

Всего записей: 1972 | Зарегистр. 04-11-2010 | Отправлено: 15:02 17-02-2021 | Исправлено: insorg, 15:03 17-02-2021
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 4)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru