» FreeArc: бесплатный open-source архиватор - Часть 3

Набираю просто freearc, пишет permission denied. Набираю sudo freearc, спрашивает, как и положено, пароль, а потом пишет command not found. Система Убунту 9.10

Цитата:

sudo make install.

сделай без sudo, у тебя права неправильно поставились из-за него

Установил без sudo, то же самое. Даже когда указываю точный путь

sudo /usr/local/bin/freearc

говорит, что нет такой команды. А без sudo ругается на отсутствие прав.

sudo make uninstall
make install

затем перезапусти терминал на всякий случай, у меня это иногда требовалось. а deb/rpm тебе не пойдёт? они есть на сайте

deb пакет был бы в самый раз, но для версии 0.6 я видел только rpm, может я чего не заметил?
А проблему я таки выявил. Как оказалось, после установки у файлов arc, unarc и freearc не стояла галочка "позволить выполнение как программы". Поставил её и всё заработало. Другой вопрос, почему так странно поставилось при установке...

Добавлено:
программу запустил, но работает она как-то криво.
Пытаюсь создать архив папки размером где-то 4 гига. Начинается создание, добавление файлов, но на каком-то этапе (вот на каком, не заметил, отошёл) процесс прерывается, опять вылазит в окно программы, где показываются файлы, а внизу ошибка написана: ошибка записи (диск полон). На диске свободно 100 гигов, неужели программе мало?
З.Ы. архивирую в режиме максимального сжатия, остальные параметру по умолчанию.

временный каталог назначь

deb был для rc версии, я их делать не умею

Поставил временную папку, резко упала скорость архивирования.
Раньше была в начале 1 Мб/сек и постоянно росла, теперь в начале 500 кб/сек и постоянно падает.
И как отключить отображение в просмотровике программы скрытых файлов и папок?

никак

Использую полную версию FreeArc 0.61 и Far 2.0 x64 b1362, Windows 7 Ultimate x64. В каталог Formats Multiarc добавил FreeArc.fmt и дописал custom.ini, unarc.exe положил в папку Far.

Архивы через Multiarc создает нормально, но вот при распаковке вообще не извлекает папки. Если зайти внутрь архива в Far и попытаться вручную скопировать папки или находящиеся внутри этих папки файлов, то изображается работа в консоли, но ничего не копируется. Если попытаться удалить внутри папки в архиве какой-нибудь файл, то тоже самое, но при этом меняется дата модификации архива, а размер его остается прежним. При работе через графическую оболочку все получается как надо.

Что я делаю не так?

slech
ты бы хоть сам прочёл


Цитата:

при распаковке вообще не извлекает папки

может проблема в 2.0? пустые папки могут неправильно обрабатываться - есть ещё такая недоработка, а файлы должны копироваться/стираться

Цитата:

пустые папки могут неправильно обрабатываться

Папки не пустые.
Есть архив, в котором есть файлы и папки с файлами. С файлами просто все операции проходят нормально, а вот распаковать или удалить папку или файлы в ней - не получается. Причем удаление не проходит не только в Far, но даже через графическую оболочку FreeArc. Пишет все Ок, но файл остается на месте. Хотя распаковку папок и отдельных файлов в ней графическая оболочка выполняет.

Так из за чего падает скорость? В настройках написано 3 Мб/сек, а у меня несколько сотен килобайт!
Проц AMD Athlon II 240, двухъядерный, с частотой 2.8

Цитата:

В настройках написано 3 Мб/сек, а у меня несколько сотен килобайт!

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


Цитата:

Так из за чего падает скорость

падает в каком смысле? по сравнению с началом сжатия - например потому что сначала был большой файл а затем пошли мелкие

Bulat_Ziganshin
Наверное тебе уже задавали этот вопрос, но все равно спрошу планируется ли в ближайшем будущем встроить srep во freearc??

В опции -ma- архиватор freeArc, как я понял, использует специальные алгоритмы для типов файлов, описанных в файле arc.groups, а для ВСЕХ остальных - основной алгоритм (например -m3). При этом сжатие некоторых файлов ощутимо замедляется по сравнению с опцией -ma9 или совсем без таковой. Видимо анализатор оптимизирует сжатие некоторых файлов или не сжимает их вовсе.

Но есть проблема. Когда включен -ma9 (кроме -ma-) некоторые тексты (.TXT) сжимаются не по алгоритму указанному в $text=..., а по автоматически выбранному основному (например -m3).

Можно ли сделать так, чтобы при опции -ma9, все файлы указанные в arc.groups обрабатывались указанными в этом файле алгоритмами, а все остальные файлы (не указанные в arc.groups) обрабатывались автоматически (как при -ma9)/?

Добавлено:
Подобрал некоторые цепочки алгоритмов, которые сжимают некоторые типы файлов сильнее чем при -mx :

/$wav=rep:512m:a99+mm:d9+tta:m3/$bmp=rep:512m:l32:h24:a99+mm+lzp:64m:32:h22:92%+grzip:m3:16m:l:a/$text=dict:p:64m:85%+delta+lzp:64m:32:h22:92%+grzip:m3:16m:l

-delta фильтр в $text давал лучшее сжатие для некоторых текстов и не влиял на остальные. grzip:m3 почему-то лучше жал, чем с опцией :m1;
-rep для $wav позволяет исключить повторное сжатие (почти)одинаковых файлов;
-rep для $bmp при его настройках сжимал лучше чем dict, но при одинаковых файлах давал сокращение повторений не полностью а на 60-80% (для файлов в пределах словаря).

Bulat_Ziganshin
Планируется исправить работу с папками и вложенными в них файлами или это пока будет фича?

Chern
сорри, я пока не нашёл время посмотреть. посмотрю - отвечу тебе конкретно

Добавлено:
DemonAk
планируется но нескоро. осенью может быть. на простом уровне (чтобы создавались врем. файлы) это не имеет большого смысла, а на более сложном требует переработки архиватора. хотя возможно надо всё же встроить по простому чтобы хотя бы на один врем. файл меньше создавать

AntonAB
читай доку - раздел, где упоминается $text и arc.groups. она описывает поведение в 0.40 и сейчас в -ma-

с -ma9, как и по умолчанию, делается вот что: сначала группы нахзаначются файлам по arc.groups, затем содержимое файлов поверяется и те из них что похожи на $compressed/$text - переводятся в соответствующие группы

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


Цитата:

grzip:m3 почему-то лучше жал, чем с опцией :m1;

на твоих файлах. впрочем, может дело в большем словаре


Цитата:

-delta фильтр в $text давал лучшее сжатие для некоторых текстов и не влиял на остальные.

имхо тексты которым поможет delta очень редки. а лишний алгоритм сжатия - это лишнее время и расход памяти при распаковке


Цитата:

-rep для $wav позволяет исключить повторное сжатие (почти)одинаковых файлов;

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


Цитата:

-rep для $bmp при его настройках сжимал лучше чем dict, но при одинаковых файлах давал сокращение повторений не полностью а на 60-80% (для файлов в пределах словаря).

какой ещё dict для bmp??? bmp файлы жмутся тоже индивидуально из-за той же проблемы

Добавлено:

Цитата:

С файлами просто все операции проходят нормально, а вот распаковать или удалить папку или файлы в ней - не получается.

значит возьми архив http://freearc.org/download/testing/a-dirs.arc

у меня в far с ним всё в порядке (far 1.75 + arc 0.60). напиши какие операции на нём не работают. если с ним проблем нет - мне нужен архив от тебя с проблемами. хотя бы листинг от него

Цитата:

значит возьми архив http://freearc.org/download/testing/a-dirs.arc

у меня в far с ним всё в порядке (far 1.75 + arc 0.60). напиши какие операции на нём не работают. если с ним проблем нет - мне нужен архив от тебя с проблемами. хотя бы листинг от него

У меня Arc 0.61, Win 7 x64, ни Far 2.0 x64 b1362, ни сама оболочка Arc не удаляют ни папки, ни файлы внутри них. Причем оболочка рапортует, что успешно удалила.

Chern
спасибо за багрепорт, в 0.60 всё в порядке, в текущей 0.61 действительно не удаляет

Добавлено:
new version:

* Fixed: processing directories and files inside directories was broken in latest alpha
* Fixed: when filetime is in 2038+ year, archive extraction was failing. now it sets filetime to 2038-01-19, last day of Unix epoch
* arc.groups: removed .bsa from compressed files list (these days it's game format, not BS Archiver
* Unix console version: disabled progress indicator in console title
* multi-threading support: switched to using LZMA2 code, now i finally can delete LZMA 4.x code from FreeArc sources
* Unix: by default allow to allocate up to 2gb of memory

Bulat_Ziganshin
Нашел глюк (вернее последовательность действий приводящих к глюку) FreeArc 0.61 (January 26 2010).

Самый простой пример:
1) Запускаем FreeArc, выходим из папки на уровень вверх и нажимаем "Упаковать" FreeArc.url -> ОК -> Вывод в статусе сообщения о "успешном создании архива FreeArc.url.arc".
2) ошибочно (в данном случае специально) становимся на Freearc.url и нажимаем "АркИнфо" -> Окно ошибки -> Вывод в статусе сообщения "..неархив или архив поврежден ...
3) Закрываем FreeArc. Пробуем удалить Freearc.url -> файл не удаляется?!
4) Запускаем "Диспетчер задач Windows" -> остается запущенным процесс FreeArc.exe (который и не позволяет удалить Freearc.url) и его нужно завершать принудительно. После завершения файл Freearc.url удаляется!

Другой пример:
1) Перезапускаем программу и входим в каталог License\ и пакуем его содержимое.
2) ошибочно (в данном случае специально) становимся на License.txt (не License.arc) и нажимаем "АркИнфо" -> Окно ошибки -> ...
3) Закрываем FreeArc. Пробуем удалить License.txt -> файл не удаляется! -> остается запущенным процесс FreeArc.exe

Пробывал разные файлы и разные архивы (License.rar, License.7z, License.zip) - все было хорошо пока не сделал АркИнфо на License.uha (тип архива неизвестный 7z.dll) -> License.uha не удаляется. Пробывал упаковать Addons\ в Addons.arc, а потом АркИнфо на Freearc.url или License.txt -> Freearc.url или License.txt не удаляются.

В итоге получается, что если сначала Создать в FreeArc архив и потом Протестировать не его, а ошибочно другой файл (не попадающий под определение arc-архива или архива известного 7z.dll) -> FreeArc.exe виснет в памяти!
(Буду дома проверю на сегодняшней версии).

Добавлено:
Проверил - все также

Bulat_Ziganshin

Я думаю, что в связке mm+tta и rep+tta есть ошибка. При архивировании 8-битных звуковых файлов (.WAV), tta просто повторяет файл (stored) никак его не сжимая. Нормально жмет только голый tta ($wav=tta). Другие комбинации кроме mm и rep не пробовал, но подозреваю что с ними будет тоже самое. Вот .arc файлы: http://ifolder.ru/16227631

Цитата:

При архивировании 8-битных звуковых файлов (.WAV), tta просто повторяет файл (stored) никак его не сжимая.

вообще по дефолту репа не дает нормально сжимать последующему ТТА - при любых вавах, но есть исключения (по непонятным причинам). Я про это уже писал (ухудшение сжатия rep+tta). Про mm+tta - это вообще странно, толку никакого не будет.

И самое главное SREP этого недостатка лишена. Может дело в служебной инфе (имена файлов/атрибуты и т.д.)?


Цитата:

delta фильтр в $text давал лучшее сжатие для некоторых текстов и не влиял на остальные.

На структурных текстах он дает улучшение. Например файлы локализаций в играх. Да и то не всегда.

Установка Free Arc в Linux

Цитата:

Run "make install" to install Arc, FreeArc, Unarc and support files on your system.
Or, run "make local" to install with per-user settings.
Run "make uninstall" to remove all files installed.
FreeArc GUI requires Gtk+ to work.

Ubuntu Server 9.10

Цитата:

user@ubuntu:~/FreeArc-0.60-linux-i386$ make local
make: *** No rule to make target `local'. Stop.

Поставилось только так:

Цитата:

wget http://freearc.org/download/0.60/FreeArc-0.60-linux-i386.tar.bz2
bzip2 -d FreeArc-0.60-linux-i386.tar.bz2
tar xvf FreeArc-0.60-linux-i386.tar
cd FreeArc-0.60-linux-i386
make install

Цитата:

Я думаю, что в связке mm+tta и rep+tta есть ошибка

да, есть

tta производит вычитание соседних семплов и затем применяет энтропийное кодирование. mm тож производит вычитание. дальше сам сообразишь?


Цитата:

вообще по дефолту репа не дает нормально сжимать последующему ТТА - при любых вавах, но есть исключения (по непонятным причинам).

потому что в еta два анализатора - wav-заголовка (он пролетает из-за rep) и по содержимому, который не всегда правильно срабатывает. плюс rep может убрать любое число байт из файла так что границы семплов собьются и суши рябину


Цитата:

И самое главное SREP этого недостатка лишена. Может дело в служебной инфе (имена файлов/атрибуты и т.д.)?

может потому что он всегда убирает кратное 4 число байт?

Добавлено:

Цитата:

Or, run "make local" to install with per-user settings.

сейчас он всегда ставится с per-user settings. инструкцию поправлю

Bulat_Ziganshin
можно ещё разок направить на инструкцию по настройке логирования ?
в документации нашёл лишь --log=C:\log.log

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

Добавлено:

Цитата:

archive@errors:~$ arc mf -r -ag%Y%m%d archive_.arc /var/mail/archive/*error* --logfile=Maildir/mail_archive.log
FreeArc 0.60 creating archive: archive_20100203.arc
Compressing 250,597 files, 983,418,843 bytes. Processed 69.5%
ERROR: can't allocate memory required for (de)compression in lzp:64mb:90%:65:h20:d1mb:s16

лог

Цитата:

/home/archive>arc mf -r -ag%Y%m%d archive_.arc /var/mail/archive/*error* --logfile=Maildir/mail_archive.log
FreeArc 0.60 Creating archive: archive_20100203.arc using rep:96mb+exe+delta+lzma:96mb:normal:32:mc16, $obj => rep:96mb+delta+lzma:96mb:normal:32:mc16, $text => dict:64mb:80%:l8192:m400:s100+lzp:64mb:90%:65:h20:d1mb:s16+ppmd:8:96mb, $compressed => rep:96mb+tor:16mb:c3, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 305mb, decompression 201mb, cache 64mb
ERROR: can't allocate memory required for (de)compression in lzp:64mb:90%:65:h20:d1mb:s16

на сервере 4 Гб оперативной памяти.

Цитата:

потому что в еta два анализатора - wav-заголовка (он пролетает из-за rep) и по содержимому, который не всегда правильно срабатывает. плюс rep может убрать любое число байт из файла так что границы семплов собьются и суши рябину

Я почти всегда принудительно выставляю параметры ТТА (каналы/битность) на основе сжимаемых данных. Так что получается второе (суши рябину ).


Цитата:

может потому что он всегда убирает кратное 4 число байт?

Если так, то как это реализовать в РЕПе? Мож опцию такую добавить.

Кстати на счёт интеграции srep во фриарк. Чисто гипотетически. Сделать репу двухпроходной (2-pass). Первый проход делает srep, собирая статистику о повторах на больших дистанциях. После, на основе этой инфы в дело вступает РЕПа, обрабатывая только участки где имеются повторы, а остальные блоки идут сразу на обработку lzma, минуя репу. Или вообще multipass с разными смещения с каждым новым проходом.

Цитата:

на сервере 4 Гб оперативной памяти.

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


Цитата:

инструкцию по настройке логирования

нет такой настройки. есть логфайл со своим фиксированным форматом. есть скрипты на lua, но они дёргаются только при ошибке


Цитата:

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

как насчёт такого:

date >log
arc ... -i2 >>log


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

Цитата:

archive@errors:~$ arc mf -r -ag%Y%m%d archive_.arc /var/mail/archive/*error* --logfile=Maildir/mail_archive.log
FreeArc 0.61 (February 2 2010) creating archive: archive_20100203.arc
Compressed 250,619 files, 983,501,931 => 99,599,899 bytes. Ratio 10.1%
Compression time: cpu 235.04 secs, real 288.76 secs. Speed 3,406 kB/s
Deleting successfully archived files
All OK

Добавлено:
я исправил прошлый пост.

Цитата:

Compressed 250,619 files

0.61a успешно отработал.
надеюсь до мильёна файлов у меня небудет.

Цитата:

может потому что он всегда убирает кратное 4 число байт?

Если так, то как это реализовать в РЕПе? Мож опцию такую добавить.

зачем? имхо очень специфичная потребность


Цитата:

Кстати на счёт интеграции srep во фриарк. Чисто гипотетически. Сделать репу двухпроходной (2-pass). Первый проход делает srep, собирая статистику о повторах на больших дистанциях. После, на основе этой инфы в дело вступает РЕПа, обрабатывая только участки где имеются повторы, а остальные блоки идут сразу на обработку lzma, минуя репу. Или вообще multipass с разными смещения с каждым новым проходом.

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

Добавлено:

Цитата:

0.61a успешно отработал.

под linux я не умею обнаруживать сколько адресного пространства доступно, но в 0.61a возвращается фикс. значение 2гб, тогда как раньше возвращалось 4 гб

-t добавь к команде

Добавлено:
PAQer, поясняю как я понял идею с srep: обычный LZ - это поток данных, в который местами вместо данных вставлены команды "скопирукй столько-то байт из прошлого с таким-то смещением". ну и lz сэимает за счёт того что эти команды короче оригинальных данных

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