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

Ещё бы графический интерфейс к столь замечательному архиватору и цены бы ему не было.

Man_in_White
как известно в 0.41

Bulat_Ziganshin
блин, ну я ж просил:

Цитата:

только убедись что работает правильно - а то я как уж не пробывал

Код: [no]F:\FreeArc-0.40-prerelease1-win32>Arc.exe a c:\test f:\FreeArc-0.40-prerelease1-win32
ARC 0.40 (24.10) creating archive: c:\test.arc
WARNING: No files, erasing empty archive
There was 1 warning(s)[/no]

Цитата:

F:\FreeArc-0.40-prerelease1-win32>Arc.exe a c:\test f:\FreeArc-0.40-prerelease1-win32

в таком виде каталоги (пока) не архивируются



Цитата:

F:\FreeArc-0.40-prerelease1-win32>Arc.exe a c:\test "f:\FreeArc-0.40-prerelease1-win32\*"

Arc.exe a c:\test -dp=f:\FreeArc-0.40-prerelease1-win32

в противном случае это "f:" попадает в имена архивных файлов и его нужно отрезать при распаковке:

Arc.exe x test.arc -dpc:\temp -apf:\FreeArc-0.40-prerelease1-win32\

кстати, кавычки использовать не обязательно, ты ж не в юниксе. самое смещное, что точно такой же вопрос мне задавали на encode.ru

Добавлено:
gui я собирался сделать осенью, но так вышло, что вместо этого сделал encryption, linux version and delta filter

Цитата:

1) возможно ли сейчас какое-нибудь революционное появление новых алгоритмов ?
2) Будете ли вы ещё как-нибудь увеличивать сжатие/уменьшать скорость упаковки ?
3) Если откроются исхлдники допустим precomp, ccm, sbc, вам они будут интересны ?

1. такие алгоритмы уже есть - context mixing: ccm, lpaq
2. я могу вставить lpaq/uda/paq в программу, если будет достаточно желающих
3. да, конечно


Цитата:

анализировать файлы перед сжатием

Цитата:

нужно, ИМХО, что-то делать с предварительно сжатыми типами файлов

Цитата:

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

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

Цитата:

1. такие алгоритмы уже есть - context mixing: ccm, lpaq
2. я могу вставить lpaq/uda/paq в программу, если будет достаточно желающих

1) Ну дак они как видно из тестов не очень выигрывают у старых )
2) uda и paq не нужны, имхо, слишком медленные + есть PeaZip

Цитата:

Is the source code for Precomp available?
Not yet, because it is very messy at the moment, but it will be.

Добавлено:
Впрочем, это ИМХО и без precomp можно сделать для XML-ZIP:
UNZIP во временную директорию -> TAR с тем же именем - и "под пресс".

Bulat_Ziganshin

Цитата:

2. я могу вставить lpaq/uda/paq в программу, если будет достаточно желающих

вставьте paq (c разновидностями, на ваше усмотрение, коих развелось..)

В sfx - будет возможность подцеплять к sfx внешние упаковщики, т.е. при сжатии использовался внешний упаковщик, делается архив sfx + подцепляется этот внешний упаковщик (можно также упаковать его)?


Цитата:

анализировать файлы перед сжатием

Bulat_Ziganshin вроде планировалось или я уже путаться стал?

Engaged Clown

Цитата:

2) uda и paq не нужны, имхо, слишком медленные + есть PeaZip

иногда нужны и эти "тракторы"

Bulat_Ziganshin

Цитата:

Arc.exe x test.arc -dpc:\temp -apf:\FreeArc-0.40-prerelease1-win32\

Это тоже не работает
Короче ключи надо упрощать - чёрт запутается (посмотри на 7зип хотябы)


Цитата:

это сделано. читай Обработка ошибок

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

Цитата:

1) Ну дак они как видно из тестов не очень выигрывают у старых )
2) uda и paq не нужны, имхо, слишком медленные + есть PeaZip

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

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


Цитата:

Впрочем, это ИМХО и без precomp можно сделать для XML-ZIP:
UNZIP во временную директорию -> TAR с тем же именем - и "под пресс".

да, для этого просто надо добавить опцию "lossy compression", которая не переживает из-за несовпадений crc


Цитата:

В sfx - будет возможность подцеплять к sfx внешние упаковщики, т.е. при сжатии использовался внешний упаковщик, делается архив sfx + подцепляется этот внешний упаковщик (можно также упаковать его)?

нет, таких мыслей у меня не было. а может, достаточно будет возможности запустить произвольную прорамму/батник после распаковки sfx?


Цитата:

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

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


Цитата:

Это тоже не работает
Короче ключи надо упрощать - чёрт запутается (посмотри на 7зип хотябы)

последовательность команд? вывод на экран? что даёт arc l на архиве?

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

концепция опций ap/dp исключительно проста - каталог внутри архива и каталог на диске, между которыми происходит копирование

Bulat_Ziganshin

Цитата:

Цитата: Впрочем, это ИМХО и без precomp можно сделать для XML-ZIP:
UNZIP во временную директорию -> TAR с тем же именем - и "под пресс".

да, для этого просто надо добавить опцию "lossy compression", которая не переживает из-за несовпадений crc

Цитата:

Если формат официально заявлен как группа XML-файлов со стандартными именами, сжатых ZIP на среднем уровне сжатия - без дополнительных фич типа комментов или самопроверки - то, ИМХО, нужно просто проверять соответствие CRC именно составляющих данный файл-архив файлов XML, а не архива в целом...

как я это должен реалиовать? напомню, что формат zip моя программа не знает и выяснить какие там crc не сможет

имхо самое простое - преобразовыаать его в неупакованный zip (как кстати и делает precomp) и проверку crc делать на этом уровне. т.е. у lossy алгоритма в отлииче от lossless есть дополнительная пара операций - входное/выходное lossy преобраование, а crc сохраняется/проверяется для этого промежуточного
файла

кстати, precomp, как и FA с опцией -max, с этими файлами справляется

Bulat_Ziganshin

Цитата:

что конкретно ты предлагаешь выводишь в логфайл и что в еррлогфайл

в первый то что обычно + файлы(точное перечисление) учавствующие в обработке
во второй только ошибки, если последних нет - файла тоже нет

Цитата:

каталог на диске

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

Цитата:

последовательность команд? вывод на экран?

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

Bulat_Ziganshin

Цитата:

нет, таких мыслей у меня не было. а может, достаточно будет возможности запустить произвольную прорамму/батник после распаковки sfx?

Не совсем понял, уточните.

Цитата:

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

arc a a -dpc:\windows
md c:\win
arc x a -dpc:\win


Цитата:

в первый то что обычно + файлы(точное перечисление) учавствующие в обработке
во второй только ошибки, если последних нет - файла тоже нет

1. сценарии применения второго файла? чем это лучше анализа кода возврата?
2. а если файлов десятки тысяч? у меня это достаточно частая ситуация. зачем этот список файлов там нужен?


Цитата:

нет, таких мыслей у меня не было. а может, достаточно будет возможности запустить произвольную прорамму/батник после распаковки sfx?

Не совсем понял, уточните.

да, действительно, как-то не очень уточняется. в общем, проблема состоит в том, чтобы засосать в архив arc.ini файл (где сейчас настроены все внешние упаковщики), exe-файл архиватора, и все config/dll файлы, которые он использует. последнее вряд ли автоматизируется, так что выходит, надо их явно описывать при конфигурировании External compressor. так?

Цитата:

да, действительно, как-то не очень уточняется. в общем, проблема состоит в том, чтобы засосать в архив arc.ini файл (где сейчас настроены все внешние упаковщики), exe-файл архиватора, и все config/dll файлы, которые он использует. последнее вряд ли автоматизируется, так что выходит, надо их явно описывать при конфигурировании External compressor. так?

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

Добавлено:

Цитата:

в общем, проблема состоит в том, чтобы засосать в архив arc.ini файл

Весь arc.ini не надо засовывать, а то там лишняя информация может находиться (не для всех).

FreeArc 0.40 prerelease-2: добавлена rar-совместимая опция -ep и исправлены ошибки с обработкой абсолютных путей

http://sourceforge.net/project/showfiles.php?group_id=207033

ps: я также добавляю информацию о новых версиях в News tracker, но что-то не вижу способа подписаться на его рассылку

А как присоединить архиватор к Total Commander?

Kiljes
Поставить плагин MultiArc и вписать в multiarc.ini содержимое файла FreeArc-0.40-prerelease1-win32.7z\TotalCommander MultiArc plugin\freearc.addon из архива.

кстати, жалобы на работу с far/tc были? были. не вижу благодарностей

arsvrn

Цитата:

вписать в multiarc.ini содержимое файла FreeArc-0.40-prerelease1-win32.7z\TotalCommander MultiArc plugin\freearc.addon из архива.

не понял. Повтори.

Kiljes проще поступить как описано в док-ции. ты ведь её прочитал прежде чем задавать вопросы?

Bulat_Ziganshin

Цитата:

кстати, жалобы на работу с far/tc были? были. не вижу благодарностей

ну как же я тебе большую благодарность сразу после выхода первого пререлиза 0.40 отправил.

Kiljes

Цитата:

не понял. Повтори.

Не понял, чего не понял. Если не знаешь, как с мультиарком работать - заходи в тему про него (ссылка выше, где благодарность Булату).

Bulat_Ziganshin
Таки насчёт благодарностей

Подключил я это всё к ТК. Работает, медленнее, чем ZIP и 7Z, но жмёт немного лучше.

Но Вы будете смеятся - странная закономерность при работе с параметрами сжатия (изменяю их в окне, выскакивающем с началом архивации):

исходно 350 Кб (файл документации архиватора на русском)
- m2 получаем 40 Кб в архиве
- mx получаем 34 Кб
-max получаем 142 Кб !!!

Чего-то я не понимаю в этой жизни...

Bulat_Ziganshin
Булат, а каковы примерные планы дальнейшего развития FreeArc'a ? В частности когда можно ждать поддержку многотомных архивов, sfx (для начала хотя бы консольный) и т.д.

Nick222

Цитата:

-max получаем 142 Кб !!!

У меня получилось 32.9 кБ
В режиме -max для большего сжатия используются внешние архиваторы (в документации они перечислены). У тебя они есть? Если нет, то вполне можно получить такой интересный эффект.

http://www.elektronik.htw-aalen.de/packJPG/binarys/new/PackJPGv2.0.zip недоступен

Nick222

Цитата:

недоступен

И ?

http://www.elektronik.htw-aalen.de/packJPG/binaries/packJPG%20v2.0.zip

или даже

http://www.elektronik.htw-aalen.de/packJPG/binaries/packJPG%20v2.3.zip

Цитата:

http://www.elektronik.htw-aalen.de/packJPG/binarys/new/PackJPGv2.0.zip недоступен

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

кстати, здесь большая засада - если вы к примеру упаковали ccm 1.23 и затем установили ccm 1.25 - распаковываться архивы перестанут. то же самое при пересылке архивов другим людям. пока я думаю, что надо переименовывать exe-шники так, чтобы они включали номер версии (ccmx125.exe) и в программе прописывать каждую версию отдельно:

[External compressor:ccm123,ccmx123,ccm125,ccmx125]
mem = 276
packcmd = %compressor% c 4 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = %compressor% d $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

и затем в секции методов сжатия прописывать алиас на последнюю версию:
ccmx=ccmx125

тогда для сжатия будет использоваться заалиасенная версия, а при распаковке будет выбираться нужный exe-шник (поскольку внутри архива метод сжатия сохраняется после раскрытия всех алиасов, т.е. как ccmx125 в данном случае); сли же такого exe-шника нет, то программа ясно выругается "не могу распаковать метод ccmx125"


Цитата:

Работает, медленнее, чем ZIP и 7Z

какие опции с какими сравниваешь? -m2 должен быть всяко быстрее 7z, а -m1 - быстрее zip (правда пока их нельзя использовать для реальной работы - глючат)


Цитата:

Булат, а каковы примерные планы дальнейшего развития FreeArc'a ? В частности когда можно ждать поддержку многотомных архивов, sfx (для начала хотя бы консольный) и т.д.

так от вас зависит! я пока, исходя из всевозможныз пожеланий, имею такой план:

Версия 0.41: доделать archive recovery, чтоб было не хуже чем в rar
сохранять опции упаковки внутри архива - это важно, поскольку сейчас можно создать архив с -m2, к примеру, а при следующем обновлении данные начнут переупаковываться методом по умолчанию -m4
реальный индикатор прогресса (сейчас он любит надолго зависать или вообще доходит до 99.9% и только затем начинает сжимать )
выбор метода сдатия по содержимому файлов, а не только их расширениям
это самые необходимые, на мой взгляд, функции для реальной юзабельности программы

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

Цитата:

так от вас зависит!

О !

Тогда просьба вписать в список пожеланий на 0.43 - многотомные архивы (синтаксис - как в rar), ну и sfx'ы хорошо бы. Для начала тоже хотя бы консольные, а там видно будет.

Bulat_Ziganshin

Цитата:

1. сценарии применения второго файла? чем это лучше анализа кода возврата?
2. а если файлов десятки тысяч? у меня это достаточно частая ситуация. зачем этот список файлов там нужен?

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

да и вобще речь идёт об общепринятых традициях

Benchmark
Спасибо, я ступил

Bulat_Ziganshin
Почему-то у меня на многочисленных (8 тыс) мелких (2 Кб) HTML-файлах сжимает на 15-20% лучше и раза в два быстрее, чем 7Z.
За счёт чего такая подозрительная разница (режим -mx)?
Шапку я прочитал - но не верю в такие хорошие результаты...
Вроде бы Игорь Павлов сделал свой алгоритм сжатия - или в том-то и дело, что алгоритм он сделал, а продукт не довёл до ума?

И ещё:
1) Можно ли поставить на проверку на упаковку 100-200 тыс. мелких файлов - или лучше подождать следующей версии (у меня слабый комп)?
Если можно - какие настройки лучше?
2) Не будет ли утилиты автоматического тестирования данных и выставления оптимальных настроек?
Или м.б. какие-то рекомендации есть для смешанных наборов файлов (txt, html, xml, doc, xls, odt, ods, pdf, djvu)?
Главное - нужно ли руками делить файлы по группам (текст, архивы, несжимаемые) или он сам это сделает?

ЗЫ: Не хотелось бы пользоваться дополнительными архиваторами без особой необходимости - усугубляется зависимость от софта при распаковке...

ЗЫ.ЗЫ: А самопроверка архива после упаковки есть? Если да - как её включить?

Добавлено:
Продолжение экспериментов:

Попытка сжать тот же пакет (см.выше) мелких HTML с помощью 7Z на PPMD привела к некоторому увеличению размера архива по сравнению с LZMA.
Т.о. для "текстовых" файлов FreeArc явно выигрывает.

Однако, ни на "компаунд" файлах (типа DOC), ни на файлах-архивах (типа ODT) сколько-нибудь существенной разницы по скорости и степени сжатия по сравнению с 7Z я что-то не увидел...

Слабо сжимаемые файлы (PDF, DJVU) сравнить не удалось: FreeArc работал долго и дал сжатие (для 10 файлов) в 93% от исходного размера, архиватор 7Z на моём железе просто застрял с этими файлами...

ИМХО, выигрыш в 10% для файлов размером по 50 Мб - непрактичен по сравнению с непристойно огромным временем сжатия.
Я бы такие файлы просто "складировал" в архив без сжатия вообще....

Добавлено:
А нельзя ли дать юзеру возможность самому решать - как обрабатывать разные типы файлов (в общих чертах, конечно) - как это делает SQX?

Я бы разбил файлы по типам так:
- текстовые и т.п.;
- компаунд (МС Офис до 2007 и подобные);
- архивы (все уже сжатые, включая офисные);
- слабо сжимаемые (PDF-DJVU, картинки, звук, видео и т.п.);
- софт (EXE, DLL и т.п.).

Если есть сортировка и группировка файлов по типам - то это было бы оправдано...