» FreeArc (часть 4)

WiperX
http://freearc.org/research/SREP.aspx
http://freearc.org/research/SREP39.htm

если непонятно - спрашивай

Добавлено:

Цитата:

можно ли при распаковке через unarc отобразить ход выполнения как в Arc (время и проценты)?

имеется в виду unarc.exe или unarc.dll?

freearc по-умолчанию пытается сжимать файлы открытые уже для записи
в 7z z для этого есть опция -ssw
если пытаться сжимать так:
arc a -t7z -m1 archive files
то сжимаются не все файлы
когда как без опции -t все ок
что можно сделать для решения этой проблемы?
использовать 7z?

..
кстати, в обоих случаях общий объем данных и количество файлов при упаковке одинаковое
уже после различие идет

Цитата:

имеется в виду unarc.exe или unarc.dll?

unarc.exe

juvaforza
как раз и хотел бы перейти на freearc с рара т.к. архивы снимаю постоянно. то что я указал это ж не претензия к автору, это мнение простого пользователя который собирается им пользоваться постоянно и который при переходе с одного архиватора на другой испытывает некоторые трудности. если мнение не интересно тогда sorry.

Цитата:

можно ли при распаковке через unarc отобразить ход выполнения как в Arc (время и проценты)?

есть графический sfx, переиеновываешь его в archive.exe, ложишь рядом с archive.arc и запускаешь archive.exe x -dpDIR (archive.exe -h для помощи)

Цитата:

ФА часто начал падать с такой ошибкой: read: invalid argument (Bud file descriptor), после чего выскакивает окно виндовс о завершении работы программы

Подтверждаю. Вот видео и сам набор файлов: http://rghost.ru/39804078

1. Тут вот, что заметил. Если в arc.ini для внешнего компрессора указать необходимую память для упаковку/распаковки (mem=..., cmem=... dmem=...), то всё равно ОЗУ упаковки/распаковки: 4096 мб.
2. -m=ExternalCompressor1+4x4:ExternalCompressor2, то будет запущено: ExternalCompressor1 и несколько экземпляров ExternalCompressor2 (скорее всего равное количеству ядер), а это не есть хорошо. Предлагаю добавить команду для 4x4, которая бы уменьшала количество запусков ExternalCompressor2 на указанное число.
P.S. Для распаковки ExternalCompressor1 используется stdin/out, CLS.

AntikillerPM
Это ответ на ваш вопрос о сепарации параметров для новичков - она уже есть. Просто будьте внимательны, нужно только посмотреть описание поля и понять его предназначение.

Цитата:

как раз и хотел бы перейти на freearc с рара т.к. архивы снимаю постоянно.

Архивы раром сжимать и создавать в раре резервные копии - вещи разные. Если вы не делаете последнего, то этот пример вам не нужен.

Edison007007
1. это cls или external?
2. 4x4:t11:... создаёт 11 тредов. другое дело что 4x4:external у меня лично надёжно не работают. да, external compressor в моей терминологии - это именно exe, а не dll. в принципе что-то типа 4x4:t-2 для создания cpu-2 потоков могло бы быть полезным. хотя с жругой стороны - редко когда скорость разных алгоритмов одинакова, так что если у тебя есть ex1+4x4:ex2 - не факт что нужен именно N-1 поток

Цитата:

Подтверждаю

у меня этот каталог нормально сжимается с -m=lzma. посмотри, может у тебя ещё какие опции стоят или arc.ini не дефолтный


Цитата:

что можно сделать для решения этой проблемы?
использовать 7z?

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

srep:mem256mb это размер словаря? если да то в каких пределах его можно указывать?

Bulat_Ziganshin
в последний альфе с подключением срепа или прекомпа прогресбар ведет себя очень странно (перескакивает, застревает) планируете ли вы улучшить поведение прогресбара?

Цитата:

1. это cls или external?

Здесь походу мой косяк... т.к думал, что инфа об этом есть где-то в архиве

Добавлено:

Цитата:

2. 4x4:t11:... создаёт 11 тредов. другое дело что 4x4:external у меня лично надёжно не работают. да, external compressor в моей терминологии - это именно exe, а не dll. в принципе что-то типа 4x4:t-2 для создания cpu-2 потоков могло бы быть полезным. хотя с жругой стороны - редко когда скорость разных алгоритмов одинакова, так что если у тебя есть ex1+4x4:ex2 - не факт что нужен именно N-1 поток

Например precomp+какой-нибудь CM

Цитата:

планируете ли вы улучшить поведение прогресбара?

нет. это невозможно для внешних архиваторов, не использующих stdin/stdout

от меня давно требовали сделать настраиваемым набор команд в меню Explorer. сейчас я сообразил как это можно сделать и выдвигаю на вашу критику первую версию проекта. за основу возьмём существующий диалог:


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

- добавить горизонтальный разделитель
- добавить начало подменю (вводится текст надписи)
- добавить конец подменю
- добавить предопределённые команды
- добавить новую команду
- переместить выделенные пункты вверх/вниз
- удалить выделенные пункты меню

все добавления новых пунктов меню делаются после текущего выделенного. описание пункта меню состоит из:

- наименования (выводимой в меню надписи), например "Add to archive {arcname}"
- выполняемой команды, соответственно "freearc a {arcname} {files}"
- галочек - условий включения этого пункта меню (для arc sfx, arc non-sfx, non-arc архивов, не-архивов)

в наименовании команды поддерживается возможность перевода, т.е. её можно написать в виде "0864 Add to archive..." и вместо английского текста будет подставлен соответствующий русский из файла перевода. в наименованиях и выполняемых командах поддерживается макроподстановка имени выделенного файла/создаваемого архива/...

Bulat_Ziganshin
понятно. а вот например в arc можно передавать еще такие типы:
xz/wim/gzip/bzip2/tar
они видимо как-то 7z.dll отлавливаются
(ну соответственно и свои ограничения для xz/gzip/bzip2 в 1 файл)
это вообще кто либо замечал? ))

Tornado 0.6a:поддержка FreeBSD, добавленная m^2
исправлены ошибки в режимах -11..16 и -10 -x2*
исправлена ошибка в индикаторе прогресса при распаковке
запрещено использовании опции -t1 с несовместимыми с ней -p4 и -x2*

---

Tornado 0.6a:FreeBSD support developed by m^2
fixed bugs in -11..16 and -10 -x2* modes
fixed bug in the decompression progress indicator code
prohibited use of -t1 with incompatible -p4 and -x2* switches

Bulat_Ziganshin
precomp + FA
при включении в алгоритм прекомпа сжатия сейчас проходит так:
1) файлы которые должны обрабатываться этим препроцессором загоняются в архив без сжатия
2) файл обрабатывается прекомпом
3) далее идет упаковки lzma

не лучше было бы сделать этот процесс следующим образом:
1) прекомпом обрабатывается каждый нужный файл отдельно
2) далее идет упаковки lzma

или этот процесс можно было бы сделать вообще параллельным, например:
один файл обрабатывается прекомпом а дальше lzma, после обработки этого файла lzma ставится на паузу, дальше цепочка повторяется прекомп - lzma - lzma(pause) -...
аналогично и с распаковкой

преимущества такого метода:
1. выпадает объединения данных в несжимаем архив (+ скорость, - размер временной папки при упаковке / распаковке)
2. при параллельной работе размер папки с временными файлами будет минимальный (будет равен наибольшему pсf файлу)
3. этот процесс позволит сделать лучше поведение прогресс бара

возможно ли такое вообще сделать, и если возможно, то вы не хотите ли это сделать в ФА?

Bulat_Ziganshin

Про настраиваемый набор команд не подскажу.
А вот к прогресс-диалогу очень хочу вернуться!
Вот здесь это обсуждалось:
http://www.forum.ru-board.com:9000/topic.cgi?forum=5&topic=35164&start=1860#21
на этой и последующих страницах.

Прошло время, и пришло понимание,
что тот вариант, что сейчас (в версии 2013-11-11) мне ужасно не нравится!
Душа лежит к варианту вроде v5.
Но есть и свои соображения.
Я предлагаю вариант 17

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

Добавлено:
PS.
1. Просьба к цифрам не придираться - они не увязаны друг с другом.
2. В WinRAR мне раньше нравилось, но сейчас считаю, что сделано тоже неудачно.
3. Один из неплохих вариантов - winuha.

Возможно, Speed надо перенести в верхнюю часть диалога, поскольку относится к исходным данным.

Добавлено:
Возможно, самый лучший вариант,
разместить Ratio и Speed между прогресс-барами...

Добавлено:
v18



Добавлено:
Почему я предлагаю такие варианты?
Потому, что в прогресс-баре заполненная левая часть обозначает обработанную часть,
а весь прогресс-бар - все целиком.
Поэтому и цифры должны по расположению соответствовать прогресс-бару, а не так как сейчас! (соответствия по расположению нет! Все время надо напрягаться.)

Добавлено:
Если кому понравился мой последний вариант,
прошу - выскажитесь здесь.
И мне будет ясно насколько я одинок или нет, и Булат, может быть, прислушается.
(к одному моему мнению - вряд ли).

Добавлено:
А еще, если как следует подумать, надо убрать в v18 прогноз размера архива.
1. Не соответствует "всей шкале" прогресс-бара - это не размер архива, а размер данных
2. Все архиваторы сначала группируют файлы (по расширениям), и потом сжимают. В результате, при сжатии одной группы файлов, например, rar-файлов, они "прогнозируют" один размер архива, потом, когда дело доходит до .txt, архиваторы "резко" меняют свой прогноз - в общем смысла мало.
Достаточно текущего размера архива и процента сжатия.

Bulat_Ziganshin
несколько вопросов по GUI:
1. В окне Freearc выделяю файл, например, price.xls --> Упаковать - в строке "Выходной архив": price.arc

Отмечаю опцию "Сделать ЕХЕ" --> "Выходной архив" так и остается price.arc
Это возможно исправить?
(7-zip и WinRAR меняют расширение 7z -->exe и rar-->exe корректно)

2. При создании нового архива и нажатии в строке "Сжатие" на кнопку "..." выставляем, например, "Уровень сажатия" - Максимальное , отмечаем галочку "precomp" и нажимаем "Ок". ---- Строка сжатия поменялась на Максимальное: -mx -mc$default,$obj:+precomp.
Если, не начиная Упаковки (не нажать на Ок. диалога упаковки), снова зайти по кнопке "..." ) - видим что "Уровень сжатия" - Нормальное и галочка "precomp" не отмечена ------> нажимаем Ок - но Строка сжатия так и осталась Максимальное: -mx -mc$default,$obj:+precomp

Почему первый вариант установок имеет приоритет над вторым или почему не применились опции второго варианта и не поменялась срока сжатия?

Обнаружена следующая проблема.

Система стоит на диске С с FAT32.
На диске D лежит снимок диска C в формате tib, размер 9 ГБ.
Архивация FreeArc невозможна по той простой причине что он на диске C зачем-то начинает создавать временный файл более 4ГБ. Изменить временную директорию не нашел как и вообще не понятно зачем такой огромный временный файл и может его как-то разбивать.

Булат, в одной из последних версий ты сделал вот это:
* После выполнения команды "freearc a -t" окно программы не закрывается автоматически

Существует ли дополнительный ключик, чтобы вернуть старое поведение?

Цитата:

arc.ini не дефолтный

Ну да. Добавлено содержание arc-lzma-x64-filter.ini. На lzma x32 таких выкрутасов никогда не замечал. Такую ошибку выдает только lzma x64. Но т.к. методом -m=lzma я не пакую, а -mx сжимает этот каталог без проблем, то для меня эта ошибка не критична.

Добавлено:
ruduk

Цитата:

Отмечаю опцию "Сделать ЕХЕ" --> "Выходной архив" так и остается price.arc

Какой в этом смысл, главное результат. После упаковки архив всегда будет exe а не arc если поставил галочку "Сделать ЕХЕ"

coolerru
C:\!FreeArc> arc | grep pause
--pause-before-exit=PAUSE make a PAUSE just before closing program window

ищем в http://freearc.org/history/changelog_full.htm pause-before-exit:

* Added option --pause-before-exit with the following settings:
on – always make a pause
off – never make a pause
on-warnings – make pause if there were any warnings due operation
on-error – if program exits due to error

* Default settings for the option:
off – for console mode
on – for "test" command in GUI mode
on-warnings – for other commands in GUI mode

* In FileManager mode this option is ignored

Добавлено:

Цитата:

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

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

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

отдельный индикатор для текущего файла - вещь безусловно полезная, вопрос только в приоритетах

Sergey_Advisor
настройки / редактировать настройки программы / основное. там указывай расположение временного каталога.
чтобы этот временный файл при упаковке и распаковке не создавался - отключи rep, но тогда немного снизится уровень сжатия

Прекрасно! Благодарю за подсказку!

vasulpr, спасибо. Не заметил, потому что каталог не был явно прописан (просто пусто). А предложение разбивать временный файл на меньше 4ГБ для FAT в силе.

Bulat_Ziganshin
А нельзя, раз вы взялись за команды в меню эксплорер, добавить туда команду типа "умной" распаковки? Чтоб, если внутри архива находятся только файлы, они распаковывались бы в каталог с названием архива. А если они уже лежат в каталоге, внутри архива, то распаковывались бы так как есть.

Paramon111
Речь идет об юзабилити FA и о том, что если сознательно отмечать опцию, то привыкшие к 7-zip и WinRAR юзеры тоже заметят этот момент в FA.

b1745923
постараюсь сделать , но только в следующей версии. можешь здесь подписаться: https://code.google.com/p/freearc/issues/detail?id=116

Добавлено:

Цитата:

от меня давно требовали сделать настраиваемым набор команд в меню Explorer

добавил как https://code.google.com/p/freearc/issues/detail?id=383 , можете подписываться

Добавлено:

Цитата:

Здесь походу мой косяк... т.к думал, что инфа об этом есть где-то в архиве

из информации, выводимой по команде lt, в архиве сохраняется записанное между строчками с "---", а выводимое наверху - высчитывается. и для external алгоритмов берётся информация, считанная из arc.ini, которая может отличаться от имевшейся в момент упаковки:


Код: Archive type: FreeArc
Total bytes: 30,180,534
Compressed bytes: 6,697,778
Ratio: 22.19%

Directory blocks: 1
Directory, bytes: 5,047
Directory, compressed: 2,411
Solid blocks: 3
Avg. blocksize: 10 mb

Compression memory: 261 mb
Decompression memory: 198 mb
Dictionary: rep:96mb+xlzma:96mb grzip:2519kb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 4 storing
31 2,553,035 251,544 94 grzip:2519kb:m1:l32:h15
251,575 27,627,499 6,446,234 64 precomp043:cn:t-j+rep:96mb+exe+delta+4x4:lzma:96mb:normal:16:mc8
-----------------------------------------------------------------------------
162 files, 30,180,534 bytes, 6,697,778 compressed

Попытка добавить к архиву (2ГБ) информацию для восстановления приводит к сообщению: malloc: resource exhausted (out of memory).

Параметры сжатия: -mx -ld1600