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

Цитата:

плавным, но неизбежным переходом на Висту

Ну конечно - до сих пор многие профессионалы сидят на Windows 2000 - и не хотят покупать ничего другого...

Nick222

Цитата:

Ну конечно - до сих пор многие профессионалы сидят на Windows 2000

Под Win2000 (и выше) - полная поддержка юникода. Там ANSI вообще не требуется.

Цитата:

плавным, но неизбежным переходом на Висту

не будет никакого перехода на висту. Будут: win2k, winxp, win2003 и следующая после висты. длинный рог - маргетинговая ось.

[...вздыхает...]

Gideon Vi
Посмотри плз. на название топика. А потом посмотри, почему вдруг в нем речь зашла про win2k, XP, Vista и т.д.

На что и у кого будет переход - неважно, это вопрос для флейма в разделе "Операционные системы". Тут же идет разбор вопроса: нужна ли FreeArc'у поддержка ANSI-списков или нет.

Цитата:

fa 0.36 способен работать с внешними компрессорами (кроме монстра естественно)? У меня так и не получилось подключить дурилку - такое впечатление, что секции [External compressor:ххх] в arc.ini игнорируются

в 0.40 это уже реализовано. а почему ты интересуешься дурилкой? в моих тестах -m6p (т.е. с помощью ppmonstr) получилось сжатие всего на процент хуже, а скорость на порядок выше:

-m6p 7.292
-mdur 7.351


Цитата:

Очень бы хотелось видеть данную поддержку в fa поскорее. В частности Total Commander формирует списки файлов в ANSI (Windows) -

а он разве не может в oem делать списки? far точно мог. в любом случае, я поддержку utf8/ansi filelists обязательно в 0.40 сделаю


Цитата:

Но... имхо это лишний повод подтолкнуть Гислера (автора ТС) на предмет добавки опции создания юникодного файл-листа.

да, это абсолютно необходимо. хотя я думал, что это автора multi-arc надо пинать

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

Цитата:

следить за тм, чтобы все файлы и заголовк архива имели один общий пароль?

не помешало бы

Bulat_Ziganshin

Цитата:

да, это абсолютно необходимо. хотя я думал, что это автора multi-arc надо пинать

Возможно его. Я не знаю, на каком этапе в TC происходит конвертация юникодного списка в ANSI - при передаче его в Multiarc, или уже внутри самого Multiarc'a. Одним словом, кого-то из них двух.


Цитата:

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

Трудно сказать.

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

Т.е. возможность задать пароль для каждого файла иногда может пригодиться. Но в 99% случаев одного пароля на весь архив вполне хватает.

Цитата:

автора multi-arc надо пинать

Автор официально прекратил разработку.
Если что-то от него нужно - следует срочно писать в тред на форуме ТК http://forum.wincmd.ru/viewtopic.php?t=78&start=105 - может быть (50/50) он что-то очень важное сделает до того, как забросит проект совсем...

Только хамить не надо - нужно очень аккуратно просить - он и так тащил на себе проект несколько лет, после того, как его забросил Сябрик Жарский.

Bulat_Ziganshin

Цитата:

стоит ли следить за тм, чтобы все файлы и заголовк архива имели один общий пароль?

Следить стоит -- чтобы предупреждать. А вот жёстко ограничивать пользователя только одним паролем -- нет.

Цитата:

Следить стоит -- чтобы предупреждать. А вот жёстко ограничивать пользователя только одним паролем -- нет.

ok, согласен

Логфайл не имеет структуры ini-файла. Интересно что для себя ты тем не менее выбрал такую структуру в arc.ini

А если что, могу я включить FreeArc в этот проект ?

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

FreeArc.exe

MyArchive.FreeArc

Цитата:

А если что, могу я включить FreeArc в этот проект ?

если он бесплатный - да


Цитата:

Логфайл не имеет структуры ini-файла. Интересно что для себя ты тем не менее выбрал такую структуру в arc.ini

ini-файл имеет струтктуру инифайла. логфайл имеет структуру логфайла. не вижу тут ничего странного

Цитата:

если он бесплатный

винда конечно платная (некоторые это забывают), а так - ровная дорога


Цитата:

структуру логфайла.

Так вроде нет такой структуры

Короче после создания/извлечения нужно знать (автоматизированый метод) была ли ошибка и какая. Какие идеи

"исподники" - - в шапке

vito333
Однако автору это сделать проще будет.
Это также относится к Mark-у, но я уже молчу

Цитата:

Короче после создания/извлечения нужно знать (автоматизированый метод) была ли ошибка и какая. Какие идеи

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

резюме: не советую использовать freearc в таком контесте. и не обещаю, что исправлю это в следующей версии, пока у меня основной приоритет - степень сжатия. в свой to-do list занёс

Bulat_Ziganshin
1.5 года назад спрашивал - вроде оно . А если History глянуть, то FreeArc был и тогда 0.24. Или он был для внутреннего пользования?


Цитата:

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

Ждём с нетерпением.

Цитата:

если History глянуть, то FreeArc был и тогда 0.24. Или он был для внутреннего пользования?

скорее для развлечения

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

Bulat_Ziganshin
Время от времени у народа возникает вопрос: А какой архиватор может делать предварительно сравнение упаковываемых файлов для выявления одинаковых? Если выявляются копии их убирать из обработки, оставляя только что-то типа ссылки, как это примерно в "iso с оптимизацией" делается. (Как смог, так сформулировал народный вопрос.)

Такую возможность добавить можно?

из документации:

Цитата:

Дополнительные критерии отбора обрабатываемых файлов могут быть заданы опциями -ac, -n, -sl, -sm, -ta, -tb, -tn, -to. При этом отбор по атрибутам файла пока действует только во время архивации, поскольку атрибуты файлов не сохраняются внутри архив.

Атрибуты вообщем-то нужны.
Надеюсь в дальнейшем будут добавляться?

Посмотрите ПM.

Цитата:

Посмотрите ПM.

посмотрел. напиши мне лучше на Bulat.Ziganshin@gmail.com - так удобней будет общаться


Цитата:

Атрибуты вообщем-то нужны.
Надеюсь в дальнейшем будут добавляться?

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


Цитата:

А какой архиватор может делать предварительно сравнение упаковываемых файлов для выявления одинаковых?

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

в частности, freearc во-первых, помещает файлы с одинаковым размеом и расгширением рядом, во-вторых для бинарных файлов использует алгоритм rep, который находит повторы на дистанции вплоть до RAM/2

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

Ну хотябы помести (в следующей версии) в конец лога что-то типа 7-zip-овского "Everything is Ok" (конечно при условии полного успеха).


Цитата:

А какой архиватор может делать...

Реч видимо о том, чтобы вторую копию вобще не сжимать, но при распаковке файл должен быть на месте.

Предлагаю во всех подобных вариантах (в том числе и инфа для восстановления) использовать что-нибудь поточнее чем CRC32

Цитата:

Ну хотябы помести (в следующей версии) в конец лога что-то типа 7-zip-овского "Everything is Ok" (конечно при условии полного успеха).

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


Цитата:

Реч видимо о том, чтобы вторую копию вобще не сжимать, но при распаковке файл должен быть на месте.

я понимаю. просто нафига козе баян, если и так неплохо выходит?


Цитата:

Предлагаю во всех подобных вариантах (в том числе и инфа для восстановления) использовать что-нибудь поточнее чем CRC32

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

Bulat_Ziganshin

Цитата:

в частности, freearc во-первых, помещает файлы с одинаковым размеом и расгширением рядом, во-вторых для бинарных файлов использует алгоритм rep, который находит повторы на дистанции вплоть до RAM/2

Вот чисто с rep и баловался в 0.36 как-то косячно работает, ему нужно задавать размер словаря равный размеру упаковываемых файлов, чтобы он нормально работал.
В 0.40beta18.07.2007 уже лучше работает rep, но с размером словаря опять непонятно получается он должен быть примерно в 1.25 раза больше чем размер файла (самого большого файла).

К сожелению незнаю как rep должен работать в идеале, могу только говорить как работает.

Т.е. брался файлик несжимаемый, создавалось несколько копий его и упаковывались используя только rep с разным размером максимальной дистанции поиска соответствий (словаря). Обозвал метод 7k.
в arc.ini
[Compression methods]
7k = rep:90mb

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


Цитата:

во-вторых для бинарных файлов использует алгоритм rep, который находит повторы на дистанции вплоть до RAM/2

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


Цитата:

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

Включите пусть будет хоть с низким приоритетом.

Цитата:

а анализ кода возврата не устраивает?

Не всё ограничивается CMD.EXE (я его вобще не люблю)
Тем более что запуск другим приложением - единственный способ использования unicod-а

Как видиш уже ещё затронулось несколько тем

Цитата:

Не всё ограничивается CMD.EXE (я его вобще не люблю)

в общем, в план поставил


Цитата:

Тем более что запуск другим приложением - единственный способ использования unicod-а

а с этого места можно поподробней?




Цитата:

Включите пусть будет хоть с низким приоритетом.

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

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


Цитата:

Вот чисто с rep и баловался в 0.36 как-то косячно работает, ему нужно задавать размер словаря равный размеру упаковываемых файлов, чтобы он нормально работал.
В 0.40beta18.07.2007 уже лучше работает rep, но с размером словаря опять непонятно получается он должен быть примерно в 1.25 раза больше чем размер файла (самого большого файла).

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

2. rep - это просто-напросто lz77 алгоритм, приспособленный для использования в качестве препроцессора - у него нет huf/ari дожатия и он ищет только сопадения достаточно большой длины

совпадения он находит в пределах своего размера словаря, хотя 100%-ной гарантии нет (из-за коллизий в хеш-таблице). добавьте :a99 для увеличения вероятности нахождения совпадений. если и этого не хватит, можно ещё увеличить размер хеш-таблицы. например, для словаря 65-128 мб по умолчанию используется h23 (при этом развер хэша 4*2^23=32 мб), соответственно можно увеличить его вчетверо таким макаром: rep:90m:h25


Добавлено:

Цитата:

К сожелению незнаю как rep должен работать в идеале, могу только говорить как работает.

почитайте rep.cpp - там в начале подробно описано

Добавлено:

Цитата:

Вот чисто с rep и баловался в 0.36 как-то косячно работает, ему нужно задавать размер словаря равный размеру упаковываемых файлов, чтобы он нормально работал.
В 0.40beta18.07.2007 уже лучше работает rep, но с размером словаря опять непонятно получается он должен быть примерно в 1.25 раза больше чем размер файла (самого большого файла).

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

Bulat_Ziganshin

Цитата:

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

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

О чём раньше когда-то спрашивал (про оболочку) уже реализовано,
единственное, что хотелось бы, чтобы в списке файлов тоже была возможность группировать файлы, как в arc.groups.

Но так-как это архиватор к нему другие требования.
Детально отпишусь позже, совсеми пожеланиями.

Цитата:

а с этого места можно поподробней?

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

Ведь есть проги которые поддерживают unicode (все должны быть такими).

Кпримеру оболочка для FreeArc тоже должна иметь эту поддержку.

Сама ведь винда (9х просто забываем) можно сказать unicod-овская

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

Я написал небольшой обзор: Максимальное практическое сжатие: WinRK, ccm(x), uharc, FreeArc и 7-zip


Цитата:

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

не понял

Bulat_Ziganshin

Цитата:

не понял

Файл-список, который подсовываем на упаковку, чтобы там можно было тоже по группам сортировать.

Цитата:

Файл-список, который подсовываем на упаковку, чтобы там можно было тоже по группам сортировать.

всё равно не понял