» WinRAR (часть 2)

EugeneRoshal

Цитата:

для проверки наличия MSIE в WinPE

А если сначала проверять, WinPE это или "обычная" Windows?

Так в той же сборке для Европы с индексом N IE не было. Тут разве что читать Реестр, а после смотреть есть файл или нет. Долго и бестолково.

Victor_VG

Цитата:

Так в той же сборке для Европы с индексом N IE не было.

Ты не прав. Во всех Windows N присутсвует Internet Explorer.

В Windows XP N и Windows 8 N отсутствует Windows Media Player. Планировалась некая Windows 7 Е без браузера, но быстро сняли с продажи.

V0lt

Я уже точно не помню но был уверен что так было сообщено, а подымать бумаги Еврокомиссии - если смысл тратить на это время?

Сжимаю большой файл (~15 ГБ) эхотагом - сжимается все замечательно. Открываю архив, запускаю тест - процентах на 20 выдает ошибку CRC. Перепаковывал несколько раз, паковал с разных физических дисков - не помогает. Пробовал сжимать 7zip-ом - тоже самое! При сжатии пишет ОК, при распаковке - ошибка. Может я не совсем по адресу, но просто не знаю где б еще спросить... Есть мысли у кого что это за чудеса такие? Файл - выгрузка из SQL, так я пробовал заново перевыгрузить - и все тоже самое! Подумал бы на битую память, но выгрузки других баз, даже более больших, архивируются без проблем.

a2168561
Скорее всего Оперативная память битая, проверьте её.

О, уже вышла новая версия винрара! Спасибо. Обновлюсь!

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

С нужной папки копирую сразу путь и вставляю в поле,и он начинает разворачивать весь путь

Зачем тогда кнопка показать,если он постоянно автоматом весь путь разворачивает

maxvlas
WinRAR не разворачивает путь, предлагаемый по умолчанию. Для него и кнопка "Показать". Вводимый руками путь разворачивается после небольшой паузы всегда.

Очень удивило в этой теме утверждение Евгения, что сжатие текстовых файлов стало уже не нужно. У многих людей есть скачанный торрент библиотеки Lib.rus.ec с книгами в формате FB2 (utf8 текст + немного картинок). Там используются .zip архивы, которые в сумме занимают уже 126 ГБ, и этот объём постоянно растёт угрожающим темпом. К архиватору тут два требования, которые диктуются необходимостью быстро открыть любой файл для показа вложенной в него картинки-обложки или для передачи программе-"читалке":

1) упаковка должна быть или не solid, или solid, но с блоками небольшого размера, и распаковка таких блоков должна быть независимой.

2) должна быть единая таблица заголовков файлов в конце архива, иначе придётся долго читать цепочку из многих тысяч заголовоков, рассеянную в 1-2 гигабайтах.

Вот результаты теста для fb2-104215-113436.zip (4295 М -> .zip 1736 М) с указанием процентного выигрыша в сравнении с zip:


Код:
arc a -m9 -s;32m 44% неприемлемо медленное извлечение
arc a -m2 -s;8m 17% терпимое по скорости извлечение
arc a -m9 -s;8m 41% замедленное извлечение
7z a -mx9 -ms32m 29% терпимое по скорости извлечение
7z a -mx9 -ms8m 25% быстрое извлечение, но чуть медленнее RAR
rar -m5 -s- 27% быстрое извлечение (RAR3) Оптимум!
rar -m5 -ma5 -s- 8.5% быстрое извлечение (RAR5)

metatrop
Насколько я помню, фича не выпилена, а просто выключена по умолчанию. Загляните в настройки сжатия.

В "настройки" заглянуть не могу, т.к. WinRAR не использую вообще. Речь идёт о командной строке rar.exe - он поддерживает и RAR3 и RAR5, более того, RAR3 - по умолчанию, но дело в том, что единая таблица заголовков файлов появилась только в формате RAR5 и со старыми методами в принципе несовместима (если правильно понимаю).

Skif_off

Цитата:

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

Загляните, и потом поясните, где включить.
Из справки:
Цитата:

В архивах RAR 5.0 недоступны особые алгоритмы сжатия, среди которых сжатие текста, необработанных аудиоданных и полноцветных (true color) несжатых графических файлов, исполняемых файлов Itanium. Форматы необработанного аудио и полноцветной графики, распознаваемые RAR предыдущих версий, сегодня стали значительно менее распространёнными. Скорость сжатия текста на современных многоядерных процессорах слишком мала в сравнении с производительностью обычного алгоритма сжатия.

P. S. Другое дело, что Rar5 вполне понимает старый RAR, читает вообще без проблем, а если надо упаковать - кто мешает использовать rar3, и включить в нём сжатие текста.

metatrop

Цитата:

Очень удивило в этой теме утверждение Евгения, что сжатие текстовых файлов стало уже не нужно. У многих людей есть скачанный торрент библиотеки Lib.rus.ec с книгами в формате FB2

Так ведь это чуть ли не единственный на сегодняшний день случай, когда использование RAR3 текстового сжатия имеет некоторый смысл.

Если мы пакуем много мелких текстовых файлов, это, как правило, что-то однотипное: исходники, html. В этом случае solid обычное сжатие дает существенно больший выигрыш, чем не solid текстовое и, возможно, несколько больший, чем solid текстовое, которое, к тому же, распаковывается очень медленно. Не solid текстовое выиграет у не solid обычного, но если нас степень сжатия вообще волнует, такие архивы в большинстве случаев пакуются в solid, слишком велика разница.

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

И только если мы пакуем много разнотипных текстовых файлов размером не больше 10 - 20 мб каждый, чтобы скорость распаковки еще не играла роли, тогда да, не solid текстовое сжатие может быть полезно. Но фактически это сводится к ситуации "упаковать библиотеку целиком". Причем, чем дальше, тем чаще пользователь получит тексты уже пожатыми в fb2.zip, epub в zip контейнере, pdf, docx, и т.п. Сейчас текстовые форматы любят обзаводиться своим сжатием. И мало кто будет заморачиваться перепаковкой.

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

Кстати, если в .fb2 много картинок в base64, текстовому сжатию там тоже ловить нечего.

Andarin

Цитата:

P. S. Другое дело, что Rar5 вполне понимает старый RAR, читает вообще без проблем, а если надо упаковать - кто мешает использовать rar3, и включить в нём сжатие текста.

Как ранее озвучил metatrop, проблема RAR3 отсутствие единой таблицы имён файлов. В следствии чего использовать этот формат на больших архивах с большим количеством файлов может быть очень проблематично.

Добавлено:
EugeneRoshal

Цитата:

Если мы пакуем много мелких текстовых файлов, это, как правило, что-то однотипное: исходники, html. В этом случае solid обычное сжатие дает существенно больший выигрыш, чем не solid текстовое и, возможно, несколько больший, чем solid текстовое, которое, к тому же, распаковывается очень медленно.

У солид-сжатия есть свои серьезные проблемы.

V0lt

Цитата:

У солид-сжатия есть свои серьезные проблемы.

Скорее не проблемы, а своя область применения - для редко модифицируемых архивов, либо архивов, которые изменять не предполагается вовсе. В общем, для бэкапа.

Для повседневно обновляемых архивов solid слишком неудобен.

Консольный (rar.exe) в x64-версии какой - x32 или x64?

HelioSS

Цитата:

Консольный (rar.exe) в x64-версии какой - x32 или x64?

x64.

EugeneRoshal

Цитата:

x64.

Понятно.
Не совсем в тему, но почему тогда, прописывая путь к архиватору (к rar.exe) в Total Commander я не могу в нём открыть архив в Win7 x64?

HelioSS
Возможно, ТС использует х86-версию для универсальности (речь ведь о конфиге ТС, а не MultiArc, которому вроде безусловно нужна х86-версия? Лучше в теме ТС уточнять.

Benchmark

Цитата:

В общем, для бэкапа.

Разве solid-сжатие не уменьшит вероятность вытащить файлы в случае повреждения архива?

Цитата:

Разве solid-сжатие не уменьшит вероятность вытащить файлы в случае повреждения архива?

Не знаю, что теория на этот счёт говорит, но когда-то я встречался с такими повреждёнными архивами (и вроде даже с информацией для восстановления), извлечь всё не удавалось. Поэтому для важной информации solid-сжатие не использую.

WinRAR and RAR 5.20 beta 1 version

English (32 bit) http://rarlab.com/rar/wrar52b1.exe
English (64 bit) http://rarlab.com/rar/winrar-x64-52b1.exe

Skif_off

Цитата:

Разве solid-сжатие не уменьшит вероятность вытащить файлы в случае повреждения архива?

Само по себе - да, уменьшит. Но в бэкапе оно обязательно должно использоваться вместе с recovery record / recovery volume. Тогда польза есть.

А в обычном повседневном использовании solid, как правило, неудобен.

А у меня не-solid архивов практически вообще нет. arc и rar использую с recovery record по умолчанию. Если архив невелик solid ничего не замедляет. Если побольше, то применяю сжатие с раздельными solid-блоками для каждого типа расширений (7z a -mx9 -mse / arc a -se / rar отпадает). Тогда разные txt cfg ini файлики в любом случае быстро извлекаются.

В более сложных случаях, например, когда надо упаковать 5 ГБ почти исключительно чистых текстов (.txt библиотека, но преимущественно нехудожественная и нетехническая) используется solid сжатие с ограниченным размером блока. Выигрыш очень значительный в сравнении с отключением solid, т.к. много небольших файлов, а время извлечения - вполне терпимое... Тем более, что архив - для резервного диска, а на рабочем диске тексты в распакованном виде хранятся, чтобы поиск, в т.ч. regexp-поиск, быстрый был доступен (функция невозможная у либрусеков); извлекать из архива отдельные файлы нечасто требуется - как правило чтобы восстановить что-то изменённое или сравнить.

EugeneRoshal

Женя! Посмотрите пожалуйста это наблюдение из Варезника - похоже ошибка в алгоритме обработки имени выплыла (цитирую как есть):

Цитата:

perez969

Не понял что за хрень. только у меня такое или нет? на версии 5.2
После создания архива, имя архива повторяеться дважды .
К примеру папка winrar.new после архивации получает имя winrar.new.new
Что за обсурд.

1yrii

perez969, у меня так же. Видимо баг.

судя по описанию возникает ошибка в обработке имени (IBM PL/1) :

dcl name(char);
dcl fname(char)=L'name;
dcl ext(char)=subst(name,3,-3);
dcl outname(char)=fname.ext;

- в fname у нас всё имя вместе с расширением, а после к нему дописалось и само расширение выбранное subst() формируя ошибочное outname...

ИСПРАВЛЕНО

Поглядел сейчас на сборке от 06.10.2014 18:47:00 на ней описанного явления не наблюдаю, скажу ребятам чтобы обновились.

Victor_VG
Они тоже придумали где об ошибке писать, я ведь ту тему не читаю. Спасибо, что скопировали. Сейчас выложил исправленную английскую сборку beta 1.

Это я пытался сделать, чтобы при упаковке каталога с именем "name.rar", имя архива предлагалось "name.rar.rar", так как файл "name.rar" нам создать все равно не получится. И недосмотрел.

EugeneRoshal

Я понял что вы экспериментировали. Пусть перекачивают. Не столь и велик размер дистрибутива чтобы на сегодняшних скоростях и тарифах это стало заметно.

Цитата:

Они тоже придумали где об ошибке писать, я ведь ту тему не читаю.

EugeneRoshal
Спасибо за исправление... все ок.
Потестим далее.
Victor_VG
Благодарю за копир/перенос сообщения в эту ветку....

Если теперь winrar является портативным, то можно ли удалить его настройки из реестра? Если да, то какие (интеграция в ОС должна сохраниться)?

WinRAR 5.20 Beta 1

Russian (32 bit) http://rarlab.com/rar/wrar520b1ru.exe
Russian (64 bit) http://rarlab.com/rar/winrar-x64-520b1ru.exe