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

Bulat_Ziganshin

Цитата:

Arc.exe x http://www.haskell.org/bz/arc.arc

Ты меня очень заинтересовал !
Теперь больше всего меня интересует использование фриарк как качалку - пусть в консоли - хрен с ним. Вот только очень нужна поддержка других форматов.
Выкачивать из мси-инсталяторов(которые могут быть гигабайтными) отдельные файлы - это круто !

Цитата:

Это временно?

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

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


Цитата:

Выкачивать из мси-инсталяторов

попроси прям счас Игорю в его форуме. я с ним вчера списался, ему понравилось. 7-zip эти инсталляторы ведь поддерживает? у него к тому же и GUI есть


Цитата:

Сейчас глянул, а FreeArc при поврежденном архиве, байтик в середине занулён, на сегодня не распакует ведь архив до повреждения?

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

Bulat_Ziganshin

Цитата:

ей для этого было бы необходимо хранить crc не пофайлово, а для каждых, скажем, 64кб файла

а как у других архиваторов реализовано 7-zip, Winrar, UHARC?

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

Bulat_Ziganshin

Цитата:

у всех абсолллютно пофайлово.

а тогда как у них реализовано остановка при битом архиве (7-zip, UHARC)?


Цитата:

(ну, ты в курсе наверно что в bwt блоки и сжимаются независимо друг от друга)

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

Цитата:

а тогда как у них реализовано остановка при битом архиве (7-zip, UHARC)?

общий принцип такой: сжатые данные содержат местами избыточность, скажем в 4-битовом поле могут быть значения только от 0 до 14. если там окажется 15 - алгоритм распаковки делает вывод что данные битые

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

Цитата:

Информация об одном файле занимает в памяти порядка 500 байт.
...
При распаковке из архива лишь части файлов кол-во используемой памяти пропорционально количеству распаковываемых файлов. Таким образом, вы можете распаковывать архивы, содержащие хоть миллионы файлов, по частям, имея машину всего с 32 Мб ОЗУ.

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

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

Bulat_Ziganshin
Что значит "каталог" - если на диске, то у меня есть директории по 30 тыс файлов. Или имеется ввиду каталог в архиве?

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

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

Bulat_Ziganshin

Цитата:

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

а для solid, block-solid (c большим количеством файлов на block) не пойдёт.

Цитата:

а для solid, block-solid (c большим количеством файлов на block) не пойдёт.

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

Bulat_Ziganshin

Цитата:

это потребует всего 10мб

кстати про память (объясняю свои словами, могут быть неточности в терминах)
Получении размера свободной виртуальной памяти, или размера виртуальной памяти, которую может выделить система, или это как-то по другому называется (разобраться сам не смог).
Сейчас в FreeArc стоит ограничение размера используемой памяти в настройках алгоритмов - 1536Мб. Но и этих 1536Мб может не быть.
На чистой системе доступно примерно 1900Мб
Дальше после установки ПО количество памяти, которую сможет использовать приложение снижается.

Пример:
Панель управления - Язык и региональные стандарты - Языки - Установить поддержку языков с письмом иероглифами.
Отъест от памяти примерно 300Мб, подчёркиваю не физической памяти отъест.

Есть ли планы по этому вопросу?

Добавлено:

Цитата:

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

а если там будет пусть 10 000 000 файлов?
опять же это частность, лично я с таким количеством файлов никогда не работал.
Т.е. для такой частности возможен свой способ распаковки (не основной).

Цитата:

а если там будет пусть 10 000 000 файлов?

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

сейчас 10м файлов потребуют 5 гиг при упаковке и при распаковке. с учётом запланированного мною изменения они будут паковаться 500 отдельными кусками, требуя всего 10 мб. это с настройкой -s по умолчанию (20к файлов на каталог)

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

Добавлено:

Цитата:

кстати про память

этот вопрос я вообще не понял. fa берёт объём физ. памяти, и ограничивает алгоритмы 3/4 её объёма - это делается только для того, чтобы избежать своппинга. что ты там не устанавливай - на размере физ. памяти это не скажется

если тебя ограничение в 1.5 гига не устраивает - используй -lc и крути это ограничение в любую сторону

Bulat_Ziganshin

Цитата:

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

Это понятно, что сложно, но вопрос возник из написанного в документации

Цитата:

Таким образом, вы можете распаковывать архивы, содержащие хоть миллионы файлов, по частям, имея машину всего с 32 Мб ОЗУ.

Т.е. конечному пользователю у которого возникли сложности, придётся вручную делать распаковку, и не обязательно там будет 10 000 000 файлов.
Это крайность, если архиватор позволяет делать такие крайности, то он должен и уметь с ними работать.

Цитата:

сейчас 10м файлов потребуют 5 гиг при упаковке

вот и вторая сторона - упаковка.

Цитата:

этот вопрос я вообще не понял. fa берёт объём физ. памяти, и ограничивает алгоритмы 3/4 её объёма - это делается только для того, чтобы избежать своппинга. что ты там не устанавливай - на размере физ. памяти это не скажется

Ограничение Windows, для определённости Windows XP SP2 32bit.
Объём виртуального адресного пространства 4Гб, распределено:
2Гб - user mode (пользовательский режим), 2Гб - kernel mode (режим ядра)
Т.е. приложению (процессу) доступно примерно 2Гб виртуального адресного пространства.
Соответственно про физ.память речи не шло.

Цитата:

если тебя ограничение в 1.5 гига не устраивает - используй -lc и крути это ограничение в любую сторону

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

Цитата:

Если 75% от общего объёма физической памяти недостаточно для выбранного алгоритма сжатия, то программа автоматически уменьшает размер словаря/блока/... так, чтобы уместиться в этот объём памяти.

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

Цитата:

и ограничивает алгоритмы 3/4 её объёма

1536Мб - это 3/4 от 2Гб, а у меня на сегодня 2.5Гб опер. памяти.

PS: о крайностях, о немного заострил внимание о них, что они существуют.

Цитата:

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

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


Цитата:

1536Мб - это 3/4 от 2Гб, а у меня на сегодня 2.5Гб опер. памяти.

тогда fa по умолчанию ограничит использование памяти ~2 гигами. если ты имеешь в виду настройки для -m9, то использовать больший словарь я не стал из-за банальных проблем с подсчётом суммарного кол-ва озу - оно бы вылезло за 4 гига, а у меня 32-битные переменные в этом месте

Добавлено:

Цитата:

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

а чего там ограничивать? 2 гига для большинства юзеров, 3 - для меньшинства (кстати, сколько виста32/64 даёт 32-битным приложениям?). ограничение по физ. ОЗУ обычно является более существенным, проблемы могут быть только при наличии >=4 гиг озу в машине и ос, дабщей по 2 гига на процесс (не знаю, как при этом рапортуется общий объём озу)


Цитата:

о крайностях, о немного заострил внимание о них, что они существуют.

проблемы с распаковкой по каталогу за раз могут вознинкуть только если
1. юзер имеет >млн файлов и при этом является идиотом
2. он их упаковал с -s; и ему хватило на это памяти
3. теперь у него нет доступа к тому объёму озу, с которым он упаковывал

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

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

Цитата:

только если он использовал нестандартные параметры упаковки.

ну это уже, "юмор".

Цитата:

а чего там ограничивать? 2 гига для большинства юзеров, 3 - для меньшинства (кстати, сколько виста32/64 даёт 32-битным приложениям?). ограничение по физ. ОЗУ обычно является более существенным, проблемы могут быть только при наличии >=4 гиг озу в машине и ос, дабщей по 2 гига на процесс (не знаю, как при этом рапортуется общий объём озу)

Win 64-bit - эмуляция 32-bit, лимит 2Гб (4 ГБ, если приложение компилируется с параметром /LARGEADDRESSAWARE).
http://support.microsoft.com/kb/889654 (только тут не о Висте).

Цитата:

проблемы с распаковкой по каталогу за раз могут вознинкуть только если
1. юзер имеет >млн файлов и при этом является идиотом
2. он их упаковал с -s; и ему хватило на это памяти
3. теперь у него нет доступа к тому объёму озу, с которым он упаковывал

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

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

1. Это необязательно один и тот же юзер.
2. Профили архивирования (методы сжатия) создают один раз и потом незадумываясь их используют.
3. Это не выдумывание - то ли в топике 7-zip или Winrar, то ли где-то ещё было сообщение о проблеме с распаковкой архива из-за количества файлов, внутри была какая-то энциклопедия (что вроде 5-6 млн. если не путаю, если кто читал это сообщения дайти линк).
4. Это всего лишь заострение внимания, а не просьба бросить всё и заниматься этим.

egor23

Цитата:

3. Это не выдумывание - то ли в топике 7-zip или Winrar, то ли где-то ещё было сообщение о проблеме с распаковкой архива из-за количества файлов, внутри была какая-то энциклопедия (что вроде 5-6 млн. если не путаю

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

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

Bulat_Ziganshin

Цитата:

этот вопрос я вообще не понял.

уточнение, на практике.
система сейчас даёт использовать 1663Мб памяти
после включения опции (Установить поддержку языков с письмом иероглифами) - даёт 1327Мб.
FreeArc не воспринимает это ограничение; не выдают адекватное сообщение об ошибке (конкретику, не хватило памяти - как это делают остальные архиваторы)
т.е. хотим использовать например 1536Мб, а получаем:

Цитата:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Цитата:

только если он использовал нестандартные параметры упаковки.

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

Цитата:

делать крайним пользователя не надо, он всего лишь пользователь

Сорри, что снова вмешиваюсь (обещаю, больше не буду), но ситуация мне напоминает старый анекдот:

Пациент приходит к врачу.

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

Это я к тому, что 99.9% обычных пользователей используют стандартные пресеты, в которых за них автор заранее подумал и "сделал им удобно". Эти пресеты будут работать в любом случае.

Если пользователь лезет в _не_стандартные установки, значит он четко осознает, что делает и в состоянии оценить результат.

Benchmark

Цитата:

Если пользователь лезет в _не_стандартные установки, значит он четко осознает, что делает и в состоянии оценить результат.

Разработчик\Пользователь у каждой стороны "своя правда".

уточнение:
Win 64-bit - эмуляция 32-bit, лимит 2Гб (4 ГБ, если приложение компилируется с параметром /LARGEADDRESSAWARE).
http://support.microsoft.com/kb/889654 (только тут не о Висте).

Memory Limits for Windows Releases
http://msdn2.microsoft.com/en-us/library/Aa366778.aspx

Цитата:

Это всего лишь заострение внимания

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


Цитата:

Это не выдумывание - то ли в топике 7-zip или Winrar, то ли где-то ещё было сообщение о проблеме с распаковкой архива из-за количества файлов, внутри была какая-то энциклопедия (что вроде 5-6 млн. если не путаю, если кто читал это сообщения дайти линк).

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


Цитата:

уточнение, на практике.

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



Цитата:

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

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

Bulat_Ziganshin

Цитата:

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

пока FreeArc - CLI, это справедливо, про идиота, а когда будет GUI - это уже будет не совсем справедливо.

Цитата:

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

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

Заметел тут, пример
данные - 200Мб
lzp:200m+lzma:128m (цепочка\цифры для примера)
после обработки данных lzp получаем 12Мб, но lzma не сбрасывает размер словаря до 12Мб. Так задумано?


Цитата:

2. да, я с таким (вирт. память меньше 3/4 физичсекой) не сталкивался.

Только вопрос! А возможно обойти ограничение по виртуальной памяти раскидав данные по разным процессам (как это практически выглядит не знаю)?

Bulat_Ziganshin

Цитата:

попроси прям счас Игорю в его форуме

а толку - годы буду ждать

Цитата:

я с ним вчера списался

Цитата:

7-zip эти инсталляторы ведь поддерживает?

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

Цитата:

после обработки данных lzp получаем 12Мб, но lzma не сбрасывает размер словаря до 12Мб. Так задумано?

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


Цитата:

Только вопрос! А возможно обойти ограничение по виртуальной памяти раскидав данные по разным процессам (как это практически выглядит не знаю)?

ага. я "раскидываю", записывая промежуточные данные на диск


Цитата:

а толку - годы буду ждать

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

Bulat_Ziganshin

Цитата:

ага. я "раскидываю", записывая промежуточные данные на диск

аспект с промежуточными данными тоже интересен, и даже, может быть, очень интересен.

кстати про промежуточные данные
Просьба:
Добавьте вывод размеров промежуточных данных в вывод отладочной информации.
Для тестовых нужд.

http://forum.compression.ru:8080/viewtopic.php?t=2081

Цитата:

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

Было б упущение если не добавили: чем же жать тогда просто *.wav в дистрибах (из-за нескольких небольших wav цеплять внешний упаковщик?) или в игрушках (где ресурсы лежат в крупных файлах, тот же HL2).

Bulat_Ziganshin

Цитата:

а чего там ограничивать? 2 гига для большинства юзеров, 3 - для меньшинства

а FreeArc с параметром /LARGEADDRESSAWARE откомпилировать возможно?
В свете этого:
Win 64-bit: 32bit процесс -лимит 2Гб (4 ГБ, если приложение компилируется с параметром /LARGEADDRESSAWARE)

Цитата:

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

добавил в планы, полезная вещь


Цитата:

Было б упущение если не добавили: чем же жать тогда просто *.wav в дистрибах (из-за нескольких небольших wav цеплять внешний упаковщик?)

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


Цитата:

а FreeArc с параметром /LARGEADDRESSAWARE откомпилировать возможно?

провентилирую. у меня ведь основной язык haskell и компилятор - mingw, а не visual c


да, кто ещё не в курсе - fa занял три первых места в MFC efficiency rating, как собственно и ожидалось если бы он протестировал ещё и -m2 - было бы четыре первых места

Bulat_Ziganshin

Цитата:

fa занял три первых места в MFC efficiency rating, как собственно и ожидалось

Даже если посмотреть на рейтинг сжатия, где FreeArc 19-й, он единственный среди "зубров компрессии" обладает быстрым сжатием и, что еще важнее, очень быстрой декомпрессией. Остальные с точки зрения "тормознутости" для практического использования малопригодны.

По скорости разве что CCM неплох, но он, во-первых, симметричный, поэтому по скорости распаковки в разы проигрывает FA, а во-вторых примитивен по функционалу. Так что тоже не конкурент.


Цитата:

я потратил на прикручивание tta порядка месяца

Кстати, а почему именно TTA, а не FLAC или WavPack ? Просто интересно.