» FreeArc (часть 4)

UbiSergei
Вы постоянно путаете.
В WinRAR как раз по-файлово.

ну тома - это архивы созданные им ))) неправильно выразился просто )))
и еще при попытке распаковать архив с помощью ISDone Unarc.dll возвращает мне код ошибки -2(Unsupported compression metod)

Shuld
Спасибо за поправку. Давно им не пользовался.

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

Пока занимался своей разработкой, случайно получился эксперимент.
Имеем 3 папки, в каждой папке набор файлов с системного диска разных ос.
(dll,exe,mui,inf и тд. и тп.)

1. файлов 57671, размер 8,86 Гб.
2. файлов 79349, размер 13,57 Гб.
3. файлов 75584, размер 12,21 Гб.

После сжатия всех папок (rep:256mb+tor:15, сортировка -dsgercpn) получаем размер архива 2,43 Гб. (2 613 137 764)

Удаляем в каждой папке дублированные файлы. Получаем:
1. файлов 37124, размер 4,96 Гб.
2. файлов 49469, размер 7,62 Гб.
3. файлов 49895, размер 7,19 Гб.

После сжатия: (rep:256mb+tor:15, сортировка -dsgercpn) получаем размер архива 2,42 Гб. (2 605 761 577)

Вывод: rep прекрасно справляется с дупликацией файлов.

Shuld
по сравнению с tor:1 он и быстрее, и жмёт лучше. вот здесь например можешь глянуть: http://encode.ru/threads/1591-zpaq-benchmarks

вообще за исключением quicklz, это лучший из максимально быстрых алгоритмов. другое дело, какой в них смысл - в freearc xlz4 упирается в скорость не самого lz4, а того треда архиватора, который читает данные и вычисляет их crc

hammerxp1
Вывод: в данном случае rep со словарём 256 мб прекрасно справляется с дупликацией файлов поскольку rep:256m по определению не может найти повторы на расстоянии больше 256 мб, очевидно что в данном случае -dsgercpn успешно переупорядочила файлы так, чтобы повторы находились на меньшем расстоянии. но не всегда это возможно, для таких случаев и нужен srep, который находит повторы на всём объёме данных

Добавлено:

Цитата:

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

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

Цитата:

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

Спасибо.


Цитата:

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

Ошибка выдается в двух случаях:

1. добавление кода при сжатии (сразу выставляется 3 галки - сжать, код, sfx). При начале работы (уже после сжатия) он и вылетает, еще до добавления кода.
2. командой добавить код к архиву (там галки сжатия нет, есть только галка код)

Я как не смог добавить код сразу решил сначала сжать, а потом добавить код но ничего не получилось.

Цитата:

Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?

там много всего намешано. -mt по умолчанию выставляется в кол-во ядер/потоков cpu. в 4x4 можно явно укзаать числдо потоков упаковки с помощью :t, по умолчанию оно приравнивается к опции -mt. после того как параметр же таким образом задан, arc проверяет хватит ли памяти для упаковки и если нет - обрезает его. при этом даже если вы явно задали :t при сжатии - он вырезается из записываемого в архив определения (смотрится командой arcindo/lt) исходя из предположения что этот параметр вы задали для сжатия, а при распаковке могут быть какие угодно (и неизвестные заранее) условия

при распаковке происходит примерно то же самое, только :t у нас понятно никакого нету - ему неоткуда взяться. но это делает arc. как работает unarc и как он определяет размер ОЗУ в виртуалке - надо посомтреть, помнится мне что там что-то проще сделано поскольку это отдельный алгоритм на C++, а основной в arc на хаскеле. опцию -mt в unarc наверно надо добавить для таких горемык

если tor:15 близко к lzma сжимает - его и используйте. добавьте ещё :c3 - это ускорит распаковку


Цитата:

Кстати tor:16 при упаковке тоже не хватает памяти.

с гигом озу? ну да, ему 1.5 гига нужно (с дефолтным 128 мб словарём), как и lzma:max. вообще с 40 гб файлом надо в сторону srep смотреть, вроде есть cls-srep.dll для его распаковки на лету

встроил ли автор возможность делить архив на тома?

hammerxp1
если интересуетесь сжатием, вот подопытный
NDP452-KB2901951-x86-x64-DevPack.exe 328МБ
http://www.microsoft.com/en-us/download/details.aspx?id=42637

содержимое можно сжать сильнее, как минимум до 150МБ

QSQ
нет, я займусь этим только в след. версии

опцию -mt в unarc/dll/sfx приделал

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

Цитата:

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

3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!

4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час.

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

А как быть с этим:

lz4 1.3 -c0t1
disqualified: crash while decompressing

lz4 1.3 -c0t2
disqualified: crash while decompressing

lz4 1.3 -c0t3
disqualified: crash while decompressing

lz4 1.3 -c0t4
disqualified: crash while decompressing

lz4 1.3 -c1t4
disqualified: crash while decompressing

lz4 1.3 -c2t4
disqualified: crash while decompressing

http://compressionratings.com/sort.cgi?rating_sum.full+6ne_old+p3

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

Добавлено:

Цитата:

и что в нём за проценты - степень сжатия?

Верхний прогресс-бар - обработанные исходные данные/ все исходные данные

Нижний прогресс-бар - текущий размер архива/ все исходные данные.
Когда сжатие закончится - это будет процент сжатия.

Вот окно добавить код.

http://s59.radikal.ru/i163/1203/e3/70a59663ade9.jpg

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

4 года новой паблик версии нет. роадмэп завис на 2012 году.

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

Sergey_Advisor
вот первая же строка - сжатие. другое дело что галка там не отмечена. а вот 100% RR при немаленьком размере архива - это жесть. советую вам par2 использовать для таких вещей

aslav
Постоянно выходят новые версии.
И в этом году уже были.
Вы в топике ссылку
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=0&limit=1&m=1#1
смотрели?
Или здесь:
http://freearc.org/Download-Alpha.aspx
Я бы версией 0,666 пользоваться не советовал - в ней есть ошибки.
Почему автор не обновляет релиз?
Не знаю. Ищет идеала...

Shuld
понятия не имею. а тебе что, скорости -m1 не хватает? помнится, у тебя оно в диск упиралось

Цитата:

опцию -mt в unarc/dll/sfx приделал

Просто отлично! но, как работает можно поподробнее,и где скачать, потестить.

Цитата:

с гигом озу? ну да, ему 1.5 гига нужно

Упаковываю я на мощной машине, это распаковывать пытаюсь на слабых конфигурациях.

Идея про дубликаты файлов:
Под свои потребности пока что реализовал так: написал махонькую программку,перед упаковкой она ищет дубликаты файлов, создает txt файлик в корне упаковываемой папки, в нём чётные (отсчёт с нуля) строки это относительные пути к файлу оригиналу, не чётные это пути к файлу дубликату. Потом пробегается по нечётных строкам и удаляет все файлы.
Далее упаковываем, а когда распаковываем архив запускается программа опять, она берет файл с чётной строки и копирует его в путь нечётной.
Примерно так выглядит txt:
\test\file1.dll -чётн
\test\1\file1.dll -нечётн
\test\file1.dll -чётн
\test\2\otherfile1.dll -нечёт (имя может быть другим, а содержание тоже)
\test\file2.exe
\test\2\file2.exe.bak

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

Цитата:

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

Так она там и не стояла, а ошибка все равно вылазит. Вот попробовал на маленьком архиве.

1. Сжал как обычно -mx -ld1600m
2. Командой добавил код для восстановления (галки сжатия нет и я ее не убирал! версия FreeArc 0.67 (March 18 2011))


Цитата:

а вот 100% RR при немаленьком размере архива - это жесть. советую вам par2 использовать для таких вещей

А в чем фишка? Тут все одним файлом, места у меня навалом, а современные диски время от времени любят сыпать плохими секторами. Если бы эта программа использовала новые коды коррекции, а не коды Рида-Соломона.

Добавлено:
Вот еще раз проверил:

1. Сжатие образа диска 9ГБ в 2ГБ.
2. Выбор пункта добавить восстановление.
3. Галочки сжатия нет.
4. Сортировка списка файлов.
5. Сообщение об ошибке.

Да.
А есть смысл для экспериментов какую-нибудь программу RAM-диска использовать?
(у меня win-7 32 разр., а ОЗУ 4 Гб).

12345

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

извиняюсь, но не знаю где спросить
<offtopic>
Как можно распаковать InnoSetup с данными пожатыми FreeArc-ом? Не очень хочется запускать инсталлятор который зачем-то требует админ-привилегий и как минимум гадит в пуск, реестр и тп. 95% случаев всё прекрасно работаeт без каких либо записей в реестре, для оставшихся 5% можно почитать скрипт и вручную добавить то что нужно
innounp данные не распаковывает, только скрипт установки и то что в setup.exe/.bin

В некоторых случаях архивы еще и зашифрованы, пароль видимо тоже зашит в инсталляторе, как его извлечь?
</offtopic>

Sergey_Advisor
проблема в том, что вся информация для восстановления хранится в RAM, причём память выделяется одним блоком. поэтому её размер не может быть больше размера наибольшего непрерывного блока ОЗУ (диалог Settings/Information)

freearc использует xor - намного более примитивную схему коррекции ошибок, чем коды RS. вообще это совсем не моя область, но я думаю, что par2 и 20% инфы - вполне достаточно для любых сбоев. дальнейшее повышение надёжности хранения данных - за счёт хранения копий на разных носителях (внешние диски, интернет, dvd, usb-стик)

useretail 02:03 02-06-2014
Цитата:

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

Как вариант: Sandboxie или виртуалка.