» FreeArc (часть 4)

ну и пусть используют, что за горе ?
Удобство интерфейса (gui, интеграция) и достаточное количество поддерживаемых архивов (zip rar 7z) - вот главное преимущество WinRAR.

нет. читай доку на -mc и srep

Прошу прощения, возможно вопрос уже поднимался, я не нашел. Мой пример: файл 12Гб (игра с установщиком на IS, дефолтная распаковка происходит при помощи IsDone). 2 .arc архива упакованы в 1 srep и снова в arc. При установке возникает ошибка в CRC и всё отменяется. Разархивировал .arc, попробовал напрямую srep -d, то же самое - ошибка, прекращение распаковки. Открыть файл упакованный srep в архиваторе нечем, FreeArc не берет (возможно есть способ подключить srep, чтобы брал?). Есть ли способ при распаковке не останавливаться при ошибке, а пропустить и продолжить разархивацию?

Вобщем, как я понимаю, то ли мы друг друга не понимаем, то ли что-то не так.
Ты сам ясно дал понять, что во времена 0.40, по которой дока и написана, srep ещё не было (был просто rep, что является чем-то совсем другим). Соответственно, в этой самой "доке" нет даже слова "srep", не говоря уже про то, чтобы о нём что-то найти с ним связаное.
Все упоминания "-mc" сводятся к пункту "Мультимедиа-сжатие", в котором описывается как отключить (!) доп.алгоритмы сжатия, но не задействовать внешний.
Как я уже заметил, по сути arc опирается в основе на алгоритм lzma, а это многое проясняет. Следовательно, теперь я могу более-менее понятным языком для нас обоих сформулировать что мне нужно: максимальное сжатие lzma со словарём 512 Мб + использующий аналогичное количество памяти srep (он, как я пронимаю, обработает схожие данные на расстоянии до 5 гигов, чего мне полностью достаточно), особых ограничений к количеству памяти для упаковки не представляется, но для распаковки допускается выделить полгига, чего для lzma512mb вполне достаточно. Собственно, это и всё, что нужно. Напиши, пожалуйста, как конкретно будет выглядеть строка параметров для этого случая.
Только пожалуйста, не нужно посылать в очередной раз, ибо из-за этих посылательств мы торгуемся уже который день, а толку не появляется.

И ещё по этой же теме. Частенько попадаются репаки игр в этом самом ARC (только расширение хитрые люди на bin меняют) в паре с установщиком. Сначала распаковывается сам arc'овый архив, получаем некий архивчик .srep и потом распаковывается он. Каким способом реализуется подобное извращение?

Aroyl

Цитата:

возможно есть способ подключить srep

смотри "How to set up FreeArc to use new SREP in filter mode" на этой странице последний вариант подключения

Все ясно..Все на много проще оказалось. В архиве с помощью опции -dm задается шифрование заголовка (например -dmlzma:max+aes-256:n1000:r0:i468e35b8f8bb5b8cbb18acde686a6eac:sccb333390bd3fbde1a85c734cbf280f14e7131e2c4d4446e96d548ab91f1261c:c0a73 . Эти цифры я взял просто сжав архив с произвольным паролем и посмотрев его алгоритм упаковки). Такой архив freearc.exe вообще не открывает даже с паролем (пароль якобы верный, но говорит ошибка в заголовке), а unarc.dll корректно распаковывает без использования пароля.
Bulat_Ziganshin
заголовки на самом деле не шифруются что-ли? Или же так просто можно без пароля расшифровать шифрованные данные?


Добавлено:
P.S. наверн немного не верно обзываю, но я имел ввиду, что заголовки=каталог архива

Aroyl

Цитата:

Есть ли способ при распаковке не останавливаться при ошибке, а пропустить и продолжить разархивацию?

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

круто
буду знать как защитить от всяких не угодных )))
я проверил
можно даже сделать так
-dmlzma+aes
или просто так -dmaes
там не будет хеша
тоже после этого просит пароль

SREP 2.0 was released:

* -m3: new default compression mode that finds byte-exact matches; so srep:m3 outperforms rep+srep:m2
* -temp=FILENAME option that allows to use stdin-to-stdout mode without any restrictions (all external data required for compression/decompression are stored in this file)
* -c option to explicitly specify hash chunk size
* -s option to specify size of input data
* "srep file" and "srep file.srep" syntax now supported for compression and decompression respectively, simplifying program usage and allowing to just drag-n-drop file to executable's icon in order to compress or decompress it
* on disk overflow (or other write error), program displays message, deletes outfiles and returns dos error code
* compression memory usage was reduced by 8 mb

The only change after 1.91 is -s option - it allows to compress from stdin by specifying maximum possible input data size:
cat file | srep -s100m - file.srep

By default, -s25gb is assumed (and 1 gb of memory is allocated for hashing!)


Добавлено:
Aroyl
непонятно, кто ты в этом сценарии? tсли автор репака, то зачем тебе как-то извращаться - просто не используй srep

не распаковывается на твоей собственной машине, как я понимаю?

-mc описан здесь: http://freearc.org:8001/history/changelog_full_ru.htm от 5 февраля

srep здесь: http://freearc.org/research/SREP.aspx

комстрока: -m9x -mc$default+srep:mem256m

ruduk

Спасибо большое за информацию, srep подключил.

Profrager

Тогда уж билд не srep'а, а IsDone.dll - как я писал, она ответственна в данном случае )
В моем случае было бы удобно, если бы при установке (распаковке) выводился запрос на пропуск найденной ошибки и продолжение.

Bulat_Ziganshin

В сценарии я - конечный пользователь репака, устанавливаю на своей машине. Установка игры длится больше часа, требует 41Гб места и прерывается на 75%. После чего все временно распакованные архивы удаляются и установка отменяется. Я вытащил таки из srep'а конечный .arc c файлами вручную, распаковал его Freearc'ом, просто неудобно, что часть файлов распаковалась, всё остановилось из-за одного файлика, остальные пришлось опять же вручную частями извлекать. В связи с этим я и задал вопрос - вдруг есть ключ, позволяющий arc.exe при распаковке игнорировать ошибки или хотя бы не прерывать распаковку (скажем генерировать сообщение об ошибках уже после распаковки). Как я понял, такого ключа нет.

Цитата:

заголовки на самом деле не шифруются что-ли?

это работало как шифрование с дефолтным паролем

я исправил dll: http://freearc.org/download/testing/unarc2011-09-18.7z

Bulat_Ziganshin

Цитата:

SREP 2.0 was released

увидел, обрадовался, думал увижу -m4, а нет, еще рано для него)

Цитата:

The only change after 1.91 is -s option - it allows to compress from stdin by specifying maximum possible input data size

теперь для комплекта осталось включить в freearc поддержку подобной переменной для arc.ini, чтобы корректно через stdin+stdout отрабатывало.

И как обычно большое спасибо за релиз)

Bulat_Ziganshin
Это же совсем другое дело!
Спасбо!

Добавлено:
при упаковке с параметрами
a "f:\_HL1_-m9x-lc-ld-_defPsrep256m.arc" "HL1" -m9x -i2 -lc- -ld- -di -mc$default+srep:mem256m -ag"
на 14,3% архиватор споткнулся, ссылаясь на ошибку диска, хотя диск абсолютно исправен, свободно 20 гигов из 60, NTFS.
Последние строки консоли:
Цитата:

Compressing HL1\HLSourceHDC-M2\Half-Life Source HD Cinematic Pack\bin\TrackerU
I.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source\bin\TrackerUI.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source HD Cinematic Pack\bin\ServerBr
owser.dll 14.3%
ERROR: write error (disk full?) in compression algorithm srep:mem256m

Добавлено:
при параметрах
a "f:\_HL1_-m9x-defPsrep256m_.arc" HL1 -m9x -i2 -di -mc$default+srep:mem256m -ag"
аналогично:
Цитата:

Compressing HL1\HLSourceHDC-M2\HL2-HL1mod\hl1\bin.old\client.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source HD Cinematic Pack\hl1\bin\clie
nt.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source\hl1\bin\client.dll
Compressing HL1\HLSourceHDC-M2\HL2-HL1mod\hl1\bin\client.dll
Compressing HL1\HL1\HL-1111\cl\dlls\cl.dll
Compressing HL1\HL1\HL-1111\cstrike\dlls\mp.dll
Compressing HL1\HL1\HL-1111\decay\dlls\decay.dll
Compressing HL1\HL1\HL-1111\hunger3\dlls\einar.dll
Compressing HL1\HL1\HL-1111\platform\dbghelp.dll
Compressing HL1\HL1\HL-1111\platform\SteamUI.dll
Compressing HL1\HL1\HL-1111\platform\AddOns\checkers\Checkers.dll
Compressing HL1\HL1\HL-1111\platform\AddOns\chess\Chess.dll 14.3%
ERROR: write error (disk full?) in compression algorithm srep:mem256m

Aroyl
а не проще на другой машине распаковать? у меня самого srep сбоит, я грешу на разгон

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

Bulat_Ziganshin

Вопрос с установкой решился. Вроде бы помогло увеличение объема файла подкачки (Win7x86, родные 4Гб, своп поставил "рекомендовано системой"). Ещё возможная проблема (подсмотрел на сайте где брал) - кеширование антивирусом распаковываемого файла, но это надо тестить. Распаковать на другой машине можно, только долго опять же. Всё к лучшему: пока мучался с игрой - познакомился с классным архиватором) Надеюсь, когда-нибудь и мою просьбу прикрутишь. Удачи

insorg
места не хватает в виндовом TEMP-каталоге, используй -wf:\

Aroyl

Цитата:

В сценарии я - конечный пользователь репака,

что этого за репак (название, размер, где лежит)?

Добавлено:

Цитата:

конечный .arc c файлами вручную, распаковал его Freearc'ом

дайте результат с этого фала
arc lt file.arc

Цитата:

это работало как шифрование с дефолтным паролем

так если говоришь шифрование с дефолтным паролем, тогда и (free)arc.exe надо править, они ж пакуют так, что Unarc.dll легко может распаковать каталог архива с заданным при упаковке произвольным паролем.

Добавлено:
С новой дллкой архивы с паролем норм распаковываются теперь, но если поставить опцию -hp, то косяк вылезает. Что-то все таки с шифровкой заголовков не так в пакерах

SREP 2.91 alpha:

* -f: future-LZ compression; -m1f..-m3f as shortcuts
* -mBYTES for future-LZ decompression
* -nomd5: don't store/check MD5 checksum of every block

"srep -f infile" performs 2-pass compression, storing in the compressed file references to forthcoming LZ matches
"srep infile.srep" decompress such file without additional I/O - all matches are stored in dictionary. Thus, it may decompress from stdin to stdout w/o tempfiles

Unlike ordinal LZ compressors, decompressor's dictionary saves only data that will be really used at some future moment. This significantly reduces RAM needs. Examples:

1) 22 gb file from LostPlanet2 compressed down to 7 gb and require 2 gb of RAM for decompression. For comparison, REP:2gb compressed the same file only to 8.7 gb - i.e. 20% more

2) dll700.dll from my testset:
184 mb: compressed with lzma:64m
177 mb: compressed with rep:256m+lzma:64m
171 mb: compressed with lzma:256m
121 mb: compressed with srep+lzma:64m, while only 200+64 mb RAM required for decompression

The only way to limit memory usage at decompression is -mBYTES option - it will store in RAM only matches less than BYTES long. Other matches will be copied, as usual, directly from output file (therefore you can't decompress to stdout with -m). Example:
Код: srep -f infile
srep -m128kb infile.srep

Спасибо! Отлично сработало, но, к сожалению, итоговый размерчик оказался побольше, чем у 7zip:
_HL1_7z_lzma2-dict512m_.7z          1 698 158 967    22.05.12 19:20    ra--
_HL1_-m9x-defPsrep256m_wf_.arc    1 736 032 022    23.05.12 18:41    ra--
Исходя из повторяемости данных там по факту должно в итоге быть не более 1 600 000 000 байт (есть местами дубликаты по 300-400 мб, которые 256 мб словарь не "сокращает", а оставляет дублями, как, например, делает 7zip при 256Мбайт словаре).
Как я могу ещё улучшить результат?


Добавлено:
Для эксперимента задал для srep 1024 мбайта, вышло:
_HL1_srep1024_20120523184538.arc    1 736 031 774    23.05.12 19:49    -a--
т.е., выигрыш остался мизерный.

я создаю репак игры добавляю все файлы в архив FreeArc создаю скрипт после того как я создал скрипт начинаю устанавливать репак а он устанавливает только файл FreeArcа arc [more=скрин]Скачать sshot-1.png с WebFile.RU [/more]

Profrager
ещё раз - когда ты при упаковке используешь aes как метод сжатия, то он игнорирует заданный тобой пароль и шифрует дефолтным паролем. старый unarc.dll не знал что aes - метод шифрования и просто "распаковывал" его используя тот же дефолтный пароль

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

Bulat_Ziganshin
SREP 2.91 alpha

Цитата:

-l: minimum LZ match length, default 0

insorg

Цитата:

есть местами дубликаты по 300-400 мб, которые 256 мб словарь не "сокращает", а оставляет дублями, как, например, делает 7zip при 256Мбайт словаре

Что подразумевается под "дубликатами"? Файлы по 300-400 мб? SREP может найти дубликаты, только в одном файле, а не между двумя файлами. Вывод - нужно объединить "дубликаты" в один большой файл (например, TAR).

Не обращаем внимания

Bulat_Ziganshin
а как же тогда быть с ключом -hp? С ним то не распаковывается нифига.

Bulat_Ziganshin

Цитата:

srep -f infile" performs 2-pass compression

т.е. для определения совпадений необходимо в 2 раза больше времени, чем без -f ?

ruduk
Это и означает, что есть похожие и одинаковые файлы.
Обьединять в TAR не катит, ибо это сведёт на нет все прелести удобной упаковки и простой 7z@lzma-dic512Mb будет более удачным вариантом. Нужен solid-вариант.