» WinRAR (часть 2)

Ukei

Presetup -команды выполняемые ДО распаковки.

Victor_VG
Именно что хотелось бы ПОСЛЕ.

Ukei

А, тогда в SETUP скрипт повесить с rm -fR %TMPDIR% в хвосте. С Rar этот номер у меня проходил всегда, с 7-Zip нет. Как вариант использовать при распаковке запуск NSIS программы содержащей сценарий очистки и самоудаления, но программа по моему уже перебор типа из гаубицы по воробьям.

GORA2

Цитата:

Подпись появилась в версии 5b5, но ее TC открывает без проблем. Видимо еще что-то изменилось.

Я проверил на разных сборках b5 и b6. Какие-то TC открывает, какие-то - нет. Системы в этом я не увидел. Возможно, что подпись читается TC как мусор, но вылет по ошибке зависит от значений этого "мусора".

Ukei

Цитата:

Можно ли как-то средствами сабжа в настройках SFX прописать комманду, очищающую временную папку

Как тут уже сказали, с помощью программы или .bat/.cmd в Setup.

EugeneRoshal
Ясно. Сегодняшнея сборка снова стала открываться!

Victor_VG 22:03 02-07-2013
Цитата:

ну и понятно что и новый bsdrar не ругался.

А в mc открывается? У меня mc 4.8.8 + rarlinux-5.0.b6 даже rar4 не открывает:

Ставлю rarlinux-4.2.0 - открывает. Rar5, естественно, в обоих случаях не открывается. Наверно, нормальную поддержку rar5 в ФМ и надстройках типа File Roller ещё долго ждать (не переходить же на far с костылями ради этого)).

p.s. а в Total Commander ничего не мешает создать кнопку/пользовательскую команду/хоткей для просмотра/распаковки rar5.

addhaloka

У меня там сто лет как скрипт прикручен типа фаровских меню. Собственно он все и делает. Про rarlinux не скажу - у меня не стоит, да и мс держу пока довольно старый 4.6. Новый попробовал, не понравился, снёс.

Цитата:

Только сейчас обратил внимание что архив подписан сертификатом Comodo. По моему это лучшее решение задачи проверки подлинности архива.

Если когда-нибудь RAR научится подписывать такими пользовательскими сертификатами архивы, будет совсем круто. На сегодняшний день это умеет только SecureZip от PkWare.


Цитата:

Подпись появилась в версии 5b5

Там интересно получилось - архив был подписан старой AV, а сверху - сертификатом, в результате AV проверку уже не проходила. Такая вот своеобразная эпитафия самодельным ЭЦП.

Benchmark
А в чём проблема самостоятельно подписать файл отдельной утилитой? По сути это - обычный оверлей.

gjf

Цитата:

А в чём проблема самостоятельно подписать файл отдельной утилитой?

Проблемы нет, исключительно вопрос удобства - когда всё в одном месте. Собственно, про SecureZip вспомнил потому, что на данный момент он для этого и используется (для zip'ов).

Я понимаю, что последняя стабильная версия - 4.20. Но меня интересует именно Wrar410b3. Инфу о ней можно посмотреть тут: https://sites.google.com/site/newswinrar/. Что из этого описания верно? Кто юзал? Кстати, шароварная лицензия или бесплатная?

Добавлено:
Ответ получен в ПМ. По мнению одного умного человека, Wrar410b3 - подделка. Ставить не надо.

socdef

Цитата:

Wrar410b3 - подделка

Глупость.

Была такая версия, вышла 5 ноября 2011 года. Поиск по названиям файлов "wrar41b3.exe" и "winrar-x64-41b3.exe" спасет отца русской демократии. Причем искать лучше по ftp, гугл при поиске любого exe кучу дряни выдает.

p.s. Что такое "Wrar410b3" - без понятия. Настоящие имена оригинальных архивов я привел выше.

socdef

Цитата:

Wrar410b3 - подделка.

По приведённой ссылке - явно подделка. А вот информация от Benchmark - это реальность

Benchmark
Я имел в виду конкретную ссылку на конкретную прогу. Что ты называешь глупостью?

Цитата:

В ТС по Ctrl+PageDown в инсталляторы WinRAR начиная с версии 5b6 войти нельзя

Если в каталоге с Тоталом обновить файл UnRAR.dll до актуальной версии - то можно.

LonerDergunov

Кстати, и для Far Manager так же необходимо её обновление.

WinRar 4.20 (x86). Распаковываю 7z-архивы по ~11Gb каждый. В каждом архиве всего один файл (~20Gb). Начинаю распаковку, жму "Фоновый режим", программа послушно прячется в трей, но CPU всё равно занят на 98% до самого окончания распаковки. Этот глюк возникает из-за объёма архива, или же это особенности работы с 7z?


Добавлено:
CPU: Intel Pentium DualCore E5500 (2.8GHz).

А в чём глюк?
Ну он и должен все ядра прогружать, по идее.

Можно попробовать в диспетчере с одного снять галку.

reenoip
Фоновый режим - это уменьшенный приоритет, а не загрузка процессора.

V0lt
ALEX666999
не, ну я-то ожидал, что запуская любую другую ресурсоёмкую задачу CPU хоть на чуть-чуть, но будет освобождаться для её выполнения, а вместо этого система практически перестаёт отвечать на любые мои запросы и приходится ждать окончания распаковки. Кому тогда этот "Фоновый режим" нужен, если поведение системы во время работы программы не меняется?

V0lt
А по-моему, это тупо минимизация, даже без уменьшения.

reenoip
В диспетчере задач (зажми CTRL SHIFT ESCAPE) выбираем WinRar и жмакаем «задать соответствие».
Одно ядро отжимаем. Должно, по идее, помочь.

Цитата:

Примечания

Команда «Задать соответствие» доступна только в многопроцессорных компьютерах.
Применение команды «Задать соответствие» ограничивает выполнение программы или процесса выбранным обработчиком и может снизить общее быстродействие системы.

Спасибо за решение, я знаю этот способ, но мне как-то странно сначала отправлять выполнение задачи в фоновый режим, а потом ещё и соответствие ей настраивать. Двойная работа, ведь использование фонового режима как бы само по себе подразумевает, что у задачи самый мизерный приоритет среди всех, разве не так? Или я не понимаю логику автора программы?

«Фоновый» значит «на фоне». Вы печатаете в Word'e,
а программка разжимает или сжимает на бэкграунде.

По-моему, так всегда было.
Я лично, других ассоциаций при этом слове не имел.

Запуск "Microsoft Office Word 2013" при "фоновой" распаковке 7z-архива занимает 88 секунд ровно (от нажатия на ярлык до появления на экране документа с чистым листом). Т.е. почти полторы минуты запуска офисного приложения (которое в обычном случае занимает от силы 5-6 секунд) при "фоновой" распаковке архива - норма? Если да, норма, тогда ок, мой вопрос закрыт, именно это я и хотел уточнить.

reenoip

1) Во всех ОС термин "задача переднего плана" обозначает интерактивно взаимодействующую с оператором задачу, а "фоновая задача" обозначает "задача которая во время исполнения не нуждается во взаимодействии с оператором с момента запуска до момента завершения".

2) Выделение задаче ресурсов зависит от её потребностей, приоритета и наличия в системе доступных для распределения ресурсов. Этим в системе занимается планировщик задач. Выше приоритет? Если нет других претендентов то данная задача считается чаще, не более.

3) Перевод ресурсоёмкой задачи в фоновый режим не означает что её потребности в ресурсах сократятся. Просто она будет считаться без вывода своих окошек на экран и только по завершении отчитается.

4) А кто вам сказал что архивы распаковываются мгновенно? Многие ресурсоёмкие приложения часто держат часть своего исполняемого кода в ОЗУ для ускорения запуска, но М$ Офис не такой - этот сразу выскакивает как чёртик из шкатулки едва позовут и память ОС не насилует. Не просто так ходит бородатая и возрастом с динозавров шутка - "Для секретарши ставим ВинВорд шеллом - ей хватит до пенсии...".

5) Посчитайте скорость распаковки и сравните с быстродействием архиватора именно на вашей машине, а после посмотрите откуда у вас за "5 - 6 секунд" офис запускается? Для интереса выгрузите его со всеми его модулями из ОЗУ и посмотрите сколько времени он будет тогда запускаться? Думаю раз в пять - шесть дольше, если не более. НО это же Микрософт Ворд Священная Реликвия всех времён и народов....

reenoip
В фоновом режиме WinRAR снижает приоритет процесса до IDLE_PRIORITY_CLASS. Более радикальным было бы еще ограничить ввод/вывод с помощью PROCESS_MODE_BACKGROUND_BEGIN, но когда я это проверял, результат был слишком печален - скорость упаковки и распаковки падала в разы. Так что пока я этот режим использовать не стал.

Сейчас я немного переделал синхронизацию потоков при распаковке 7z и выложил новую английскую сборку beta 6. Интерфейсный поток теперь должен меньше грузить процессор. Если узким местом было именно CPU, а не диск, может помочь.

EugeneRoshal

Не думаю что узкое место в данном случае именно CPU. У самого на стенде стоит Е5400@ 2,7 GHz на связке iG41 + ICH7 с парой однотипных 1 Гб модулей Samsung DDR2-800 6-6-6-18 и работает довольно шустро, в результате чего при последовательном чтении больших файлов (> 100 Мб) диски Барракуда 11 обеспечивают скорость I/O близкую к предельной ~ 65 Мб/с. Но, если для чипсетов Intel 3-й/4-й серий ставить память с частой синхронизации не 1/2 FSB, то скорость работы дисковой подсистемы снижается в разы - на iG35 с этим же CPU и памятью DDR2-533 пиковая скорость тех же самых накопителей снижается до 27 - 30 Мб/с. Это особенность схемотехники этих чипсетов - в асинхронном режиме памяти чипсет вводит дополнительные циклы задержки на шинах для синхронизации операций I/O с FSB. Эти чипсеты синхронные с общей шиной памяти, и хотя допускают асинхронных режим работы, но в нём их лучше не использовать. Оптимальных режим для них это синхронный двухканальный режим памяти с балансировкой нагрузки по всем каналам I/O включая видео подсистему. Они конечно могут работать в двухканальном режиме с модулями разного объёма, но при этом скорость работы памяти снижается на 25% - 30%, и как следствие снижается быстродействие системы в целом. Что вполне ожидаемо.

Цитата:

EugeneRoshal: Если узким местом было именно CPU, а не диск, может помочь.

Помогло. Загрузка ЦП уменьшилась больше, чем на половину,
время работы увеличилось всего процентов на 10.

UPD: ЧСХ, это без погружения в фоновый режим.
     Тестировал на 700-метровом бэкапе в .7z.

EugeneRoshal, здравствуйте. Надо же, неужели Вы, собственной персоной?


Цитата:

результат был слишком печален - скорость упаковки и распаковки падала в разы

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

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

reenoip


Цитата:

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

Подтверждаю, у меня версия 4.20 используется для резервного копирования, после загрузки системы (предусмотрена пауза, чтобы архивация не начиналась сразу после загрузки) в фоновом режиме, с пониженным приоритетом, архивирует файлы. Да, в зависимости от количества файлов система либо немного задумывается, либо начинает сильно тормозить. А скорость архивации мне в данном случае не важна и я бы согласился на правильный фоновый режим.