» WinRAR (часть 2)

Eugene Roshal

Очень не хватает опции понизить приоритет процесса.
WinRAR пакует и сжирает весь процессор.
Хочется кнопки и еще если можно задавать количество потоков в графическом интерфейсе.

Знаю про кнопку Фоновый режим, но что при ее нажатии сворачивается в трей мне не нравится, поэтому не пользуюсь. Хочется настройку в профиль.

Сейчас иду в Диспетчер задач, там меняю приоритет и задаю количество ядер, которые участвуют в сжатии, но это грустно.

ANDE2003
Еще есть глобальная опция "Low priority" в "Settings/General".

Здравствуйте, есть задача создать несколько десятков архивов, возможно ли это сделать по очереди? Из интерфейса WinRAR похоже нет? При выделении нескольких папок, он предлагает все их упаковать в один архив.

Xenaki
____________________________________________
| | | |Файлы| | | |
____________________________________________

[Опция] - помещать каждый файл в отдельный архив.

perez969
А это разве подойдёт, если мне нужно создать из нескольких десятков папок, а не файлов, sfx архивы? Хотелось бы заходить в интерфейсе WinRAR в директорию, выделять все папки и создавать архивы по очереди, т.е. создав 1-ый архив, через пару секунд приступать к следующему. А сейчас, нужно выделить папку, нажать Alt+A и Enter и многократно повторить это.

Евгений, а подскажите - не планируется ли сделать кнопку "Свойства" на файле? Чтобы выводило как в обычном проводнике информацию:
- Безопасность (ведь винрар поддерживает архивирование с атрибутами безопасности)
- Цифровые подписи
- Подробная информация
Распаковывать из-за этого не сильно хочется каждый файл
Да, и можно ли как-то в настройках поменять алгоритм расчета контрольных сумм - с CRC32 на md5, например

melboyscout

Наверное я смогу ответить на ваш вопрос о сложности вопроса:

Цитата:

не планируется ли сделать кнопку "Свойства" на файле? Чтобы выводило как в обычном проводнике информацию:
- Безопасность (ведь винрар поддерживает архивирование с атрибутами безопасности)
- Цифровые подписи
- Подробная информация

- для вывода такой информации необходимо распаковывать каждый файл:

- атрибуты безопасности (они же права доступа) и иные зависящие от файловой системы свойства отдельного файла/каталога могут быть просто не записаны в контейнер ибо в общем случае это не задача архиватора, а задача инструментов резервного копирования файловой системы;
- для проверки ЭЦП необходимо последовательно выполнить операции:

прочитать из ресурсов бинарника сертификат(-ы если их несколько);
проверить их действительность;
просчитать хэш проверяемого файла с использованием указанного в сертификате алгоритма;
проверить совпадение рассчитанного хэша и контрольного значения записанного в сертификате;
- остальная информация читается из секции ресурсов бинарника или из потоков NTFS либо аналогичных структур других файловых систем что не возможно сделать если файл упакован либо данная информация не сохранена в контейнере;

Мой ответ относится не только конкретно к Rar, но и к любому произвольно взятому архивному формату.

Столкнулся с такой ситуацией: Распаковывал большой rar-архив, в котором было запаковано несколько маленьких rar-архивов. После распаковки один из маленьких rar-архивов оказался битым и был удалён. Тут же выполненная повторная распаковка распаковала все маленькие rar-архивы нормально.
Всё это было под Windows XP SP3 на зашифрованном в Truecrypt системном NTFS-разделе. Winrar 5.31 и rar-архивы 4-ой версии.

Выяснить хотя бы косвенно, кто виноват (Winrar, Truecypt, Windows или "железо") в ошибке записи файла архива на диск, уже не получится. Поэтому вопрос как не допустить этого в дальнейшем?
Truecrypt имеет блок шифротекста в 128 бит, который если и повреждается, то весь сразу. Жёсткий диск оперирует секторами в 512 байт (Advanced format с 4 Кбайтами пока не будем рассматривать).

В Winrar можно включить галочку "данные для восстановления". Какую избыточность в процентах для данных восстановления надо ставить в Winrar для гарантированного восстановления хотя бы нескольких подряд идущих повреждённых блоков шифротекста, а ещё лучше, наверное, сразу сектора в 512 байт? (Интересует для версии 5 rar-архивов)?
Как быть с процентами, если нужна гарантия восстановления и для архива в 256 байт, и для архива в сотни Мбайт (каждый раз указывать свой процент?)

И можно ли менять эти проценты непосредственно в GUI-интерфейсе Winrar?

Vorland

По поводу причины ошибки рискну предположить что был случайный сбой микросхем памяти причиной которого могла стать как помеха по шине или цепи питания, так и просто заряженная частица достаточно высокой энергии - подзатворная ёмкость МОП-транзистора современных микросхем ДОЗУ высокой плотности на которой хранится заряд определяющий состояние ячейки составляет порядка пикофарады (10-12F), а разность потенциалов логических уровней в ней около долей вольта, так что её заряд переключения достаточно мал и к примеру электрон или протон с энергией несколько десятков кЭВ может его изменить (у земли это событие редкое - слишком плотна атмосфера и частица быстро теряет энергию в столкновениях, на высоте 100 - 110 км от поверхности Земли такие частицы встречаются часто). Предотвратить возникновение такой ошибки можно если использовать ЕСС память, но она во первых требует специальных чипсетов, а во вторых имеет более длительный цикл ячейки т.к. дополнительно к операциям ЧТЕНИЕ - МОДИФИКАЦИЯ - ЗАПИСЬ добавляются операции ВЫЧИСЛЕНИЕ КОДА ХЕММИНГА ДЛЯ СТРОКИ, его ПРОВЕРКА и при необходимости ИСПРАВЛЕНИЕ ОШИБОК.

Воздействие помех по цепи питания можно снизить двух - трёх звенным LC-фильтром включённым между БП и питающей сетью, установкой правильно сконструированного БП с ВЧ-развязкой в выходных цепях и ВЧ блокирующих конденсаторов в цепях питания микросхем, и как минимум применением качественного (LC, дешёвый варисторный намного хуже) сетевого фильтра или ферро-резонансного стабилизатора напряжения питающей сети - по ВЧ это устройство само является не плохим фильтром, либо при нестабильной питающей сети поставить линейно-интерактивный (on-line он же Smart) UPS (Back ставить бессмысленно - время переключения достаточно велико раз и сидит на батареях до их полного разряда - два) - все UPS имеют на входе хороший ВЧ-фильтр.

Относительно процента избыточности - 3% обычно хватает с запасом, при необходимости его можно поменять в опциях для конкретной операции.

melboyscout

Цитата:

Евгений, а подскажите - не планируется ли сделать кнопку "Свойства" на файле? Чтобы выводило как в обычном проводнике информацию:
- Безопасность (ведь винрар поддерживает архивирование с атрибутами безопасности)
- Цифровые подписи
- Подробная информация
Распаковывать из-за этого не сильно хочется каждый файл

Если это делать в WinRAR, то тоже только через распаковку в %temp%. Будет ли это реализовано в таком варианте, пока не знаю. Тут еще начнутся заморочки с тем, что пользователи захотят в этом диалоге редактировать какие-то свойства файла, и придется его потом из %temp% упаковывать обратно.

Цитата:

Да, и можно ли как-то в настройках поменять алгоритм расчета контрольных сумм - с CRC32 на md5, например

Blake2sp на странице "Options" диалога упаковки.

Vorland

Цитата:

Выяснить хотя бы косвенно, кто виноват (Winrar, Truecypt, Windows или "железо") в ошибке записи файла архива на диск, уже не получится.

Тут тест памяти запустить часов хотя бы на 8. Раньше я советовал memtest86+, сейчас может что и получше появилось, я не в курсе.

Цитата:

Какую избыточность в процентах для данных восстановления надо ставить в Winrar для гарантированного восстановления хотя бы нескольких подряд идущих повреждённых блоков шифротекста, а ещё лучше, наверное, сразу сектора в 512 байт? (Интересует для версии 5 rar-архивов)?

Recovery record в состоянии восстановить непрерывную поврежденную область чуть меньше собственного размера. "Чуть меньше", так как не все данные в recovery record это помехоустойчивые коды. Часть данных - служебная информация (заголовки и контрольные суммы). В случае множественных повреждений восстанавливающая способность может быть меньше.

Цитата:

Как быть с процентами, если нужна гарантия восстановления и для архива в 256 байт, и для архива в сотни Мбайт (каждый раз указывать свой процент?)

Да. Кроме того, у архива в 256 байтов в случае сбоя велики шансы накрыться целиком вместе с recovery record и сектором диска, в котором этот архив хранился. Такую мелочь надежнее просто скопировать в нескольких экземплярах.

Цитата:

И можно ли менять эти проценты непосредственно в GUI-интерфейсе Winrar?

Размер recovery record? Можно, конечно. И в диалоге архивирования, и в команде Info.

Подскажите пожалуйста, при открытии архивов любых форматов (rar,zip,7z) с повреждениями, пускай даже 1 байта информации, гарантированно будут выдавать ошибку? Я к тому, что если архив открывается для просмотра без ошибки, то значит он не повреждён? Или только при извлечении можно это выяснить?

Eugene Roshal

Цитата:

Blake2sp на странице "Options" диалога упаковки.

md5 там нет

melboyscout

Цитата:

Да, и можно ли как-то в настройках поменять алгоритм расчета контрольных сумм - с CRC32 на md5, например

Только CRC32 для RAR 4.x и CRC32, BLAKE2sp для RAR 5.0

Eugene Roshal
я понимяю что у вас как у разрааботчика все ничтяк.
Но это можно порггасить под
скритами? Г

Xenaki

Цитата:

если архив открывается для просмотра без ошибки, то значит он не повреждён?

Вывод списка файлов без ошибок ни разу не гарантирует, что и сами файлы извлекутся без ошибок.

Sybiriak
Спасибо, не был уверен, жаль, не узнать заранее какой архив повреждён.

Eugene Roshal


Цитата:

Тут тест памяти запустить часов хотя бы на 8.

Почему такая уверенность, что проблема в памяти? Я больше склоняюсь к проблеме в дисковой подсистеме или стеку драйверов TrueCrypt/NTFS...


Цитата:

Кроме того, у архива в 256 байтов в случае сбоя велики шансы накрыться целиком вместе с recovery record и сектором диска, в котором этот архив хранился.

Может быть предусмотреть в Winrar возможность автоматического увеличения размера "recovery record" для маленьких архивов, если размер этой record (без служебной информации), вычисленный исходя из заданного пользователем процента окажется меньше, предположим, 512 байт/4 Кбайт (сектора HDD). Ведь вручную выставить больше 100% всё равно нельзя, а 100% могут не покрыть сектор диска.


Цитата:

Такую мелочь надежнее просто скопировать в нескольких экземплярах.

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

Xenaki 02:05 09-06-2016
Цитата:

жаль, не узнать заранее какой архив повреждён.

Есть команда (и кнопка в GUI) для тестирования архивов. Можно, просто, протестировать архивы.

melboyscout

Цитата:

md5 там нет

BLAKE2sp на многоядерниках вычисляется намного быстрее, чем MD5, и обладает как минимум не худшей надежностью.

Vorland

Цитата:

Почему такая уверенность, что проблема в памяти? Я больше склоняюсь к проблеме в дисковой подсистеме или стеку драйверов TrueCrypt/NTFS...

Уверенности нет. Просто по моему опыту чаще причина таких сбоев в памяти, поэтому и проверку логичнее начинать с нее. Да ее и проверить реальнее, чем остальное.

Цитата:

Уверенности нет. Просто по моему опыту чаще причина таких сбоев в памяти, поэтому и проверку логичнее начинать с нее. Да ее и проверить реальнее, чем остальное.

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

После распаковки один из маленьких rar-архивов оказался битым и был удалён. Тут же выполненная повторная распаковка распаковала все маленькие rar-архивы нормально.

была ситуация чем-то похожая.

Eugene Roshal 20:13 09-06-2016
Цитата:

BLAKE2sp на многоядерниках вычисляется намного быстрее, чем MD5, и обладает как минимум не худшей надежностью.

Eugene Roshal
рискну предположить, что интересует именно MD5 ввиду его распространённости. В 7-zip например есть SHA-1 и SHA-256, а многие просят добавить расчёт именно MD5. На SourceForge в разделе по 7-zip помню было несколько тем по этому поводу.

Цитата:

рискну предположить, что интересует именно MD5 ввиду его распространённости. В 7-zip например есть SHA-1 и SHA-256, а многие просят добавить расчёт именно MD5. На SourceForge в разделе по 7-zip помню было несколько тем по этому поводу

Дело в том, что от MD5 сейчас начинают повсеместно избавляться.

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

regist123
Цитата:

Есть команда (и кнопка в GUI) для тестирования архивов. Можно, просто, протестировать архивы.

Спасибо, я раньше просто массово открывал по 50 архивов за раз, думая, что раз открывается, значит целостность не повреждена, т.к. CRC совпал.

Benchmark 21:00 10-06-2016
Цитата:

Как криптографически стойкий хэш MD5 полностью "закончился".

Это может при каких-либо условиях повлиять на криптостойкость защищённого паролем Rar-архива?

tramparamparam02

Цитата:

Это может при каких-либо условиях повлиять на криптостойкость защищённого паролем Rar-архива?

Архивы RAR шифруются с помощью значительно более надёжных алгоритмов: AES-128 для архивов RAR 4.x и AES-256 в режиме CBC для архивов RAR 5.0. Функция деривации ключа в RAR 5.0 основана на PBKDF2 с использованием HMAC-SHA256. (Из справки). MD5 в RAR не используется.

Каким боком мд5 относится к рар?

Xenaki 05:08 11-06-2016
Цитата:

просто массово открывал по 50 архивов за раз

Если надо так массово проверять, то выделить эти архивы и ПКМ на них в контекстном меню выбрать протестировать. Предварительно разумеется надо в настройках WinRar включить такой пункт меню (если он не отображается) в разделе Интеграция - Элементы контекстного меню.

regist123
Спасибо что обратили внимание, проверил 1200 штук через интерфейс WinRAR, достаточно просто указать папку и он сам найдёт архивы, очень круто. Раньше разум игнорировал эту функцию, т.к. путал её с "Проверкой на вирусы", а там ещё и "Тест быстродействия" рядом.

Eugene Roshal

просьба добавить расширения png и gif в ключ -ms без параметров.

ANDE2003
png и gif в среднем меньше, чем jpg, удельный вес заголовков в них выше, чаще встречаются схематические и повторяющиеся изображения. Поэтому кучку маленьких png или gif порой можно пожать довольно неплохо, особенно в solid режиме. Да и много в скорости от использования -ms на них обычно не выиграть, так как средний и суммарный размер файлов чаще небольшой. Так что пока не уверен.