» FreeArc (часть 4)

coolerru
это так, в планах, но очень условно поскольку нужды большой в этом нет

FA не удобно использовать с Amazon S3 - размер загружаемого файла 5 Гб.
Нарезки сейчас не сделать на файлы не более 5 Гб.

Bulat_Ziganshin
Спасибо за ответ!


Цитата:

1. fa может использовать больше до 4 гб с опцией -lc- при ручном тьюнинге метода сжатия

Я видел эту опцию, но после прочитанного подумал, что не в ней дело:

Цитата:

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

У меня 8gb ram так почему же FreeArc хочет использовать всего 2 гб?
(размер файлов которые упаковываю ~3,5 гб - в те же 75% их можно целиком загнать...)

P.S. Может заменить в TotalCommander MultiArc plugin ANSI на UTF-8, а то с ANSI не распаковывает архив если в его пути есть русские имена?
[more]
Код: [FreeArc]
ID=41 72 43 01
IDPos = 0, -38, -39, -40, <SeekID>
Extension=arc
Description="FreeArc 0.666"
Archiver=Arc.exe
List="%P v --noarcext -- %AQA"
Format0="yyyy tt dd hh mm ss aaaaaaa zzzzzzzzzzzzzzz ppppppppppppppp rrrrrrrr nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn"
Start="^--"
End="^--"
Test="%P t --noarcext -sclUTF-8 -- %AQA"
Add="%P a {-ap%RA} --noarcext -sclUTF-8 {%S} -- %AQA @%LA"
Move="%P m {-ap%RA} --noarcext -sclUTF-8 {%S} -- %AQA @%LA"
Extract="%P e -y --noarcext -sclUTF-8 -- %AQA @%LA"
ExtractWithPath="%P x -y --noarcext -sclUTF-8 -- %AQA @%LA"
Delete="%P d --noarcext -sclUTF-8 -- %AQA @%LA"
AskHistory0=-m2
AskHistory1=-mx
AskHistory2=-max
IgnoreErrors=0
Debug=0
UnixPath=1
SkipDirsInFileList=0
SkipEmptyNames=1
BatchUnpack=1
SearchForUglyDirs=0
AskMode=2
SkipLIST=1
SkipSfxHeader=1

может немного ламерский
или не совсем в тему вопрос
но все же lzma2 же будет в FA, поэтому спрошу
почему lzma2 с a0 или hc4
при кол-ве потоков больше 3 требует больше памяти
даже чем bt2/3/4!

Задолбали авиры...Уже около пяти писем им отправил на ложное слабатывание на sfx и инсталлер(хотя инсталлер видимо распаковывает и ругается на sfx). В общем если не забуду завтра позвоню в ESET, посмотрим как они аргументируют.
UPD:

Цитата:

если вам мало встроенных алгоритмов - вы можете использовать внешние: от препроцессора сжатых данных precomp до алгоритмов максимального сжатия ccmx/lpaq/durilca/uda/paq

Не подскажете, как это сделать?

О балансировке алгоритмов сжатия "внутри" одного метода сжатия.

Bulat_Ziganshin
Несколько месяцев назад мы разговаривали на эту тему. Я "много думал", ставил эксперименты и пришел к определенным выводам.
Во многом - это вопрос идеологии. Какую идеологию выбрать?

1 Вариант. (очевидный?)
Допустим, есть данные 200 Мб, из которых 100 Мб - тексты ($text) + 100 Мб - архивы ($compressed).
Предположим, что в методе сжатия -m9,
тексты ($text) будут сжиматься 40 сек и результат будет 20 Мб
архивы ($compressed) будут сжиматься плохо, за те же 40 сек получится 90 Мб.
Итоговый результат 20+90=110 Мб за 40+40=80 сек.
Здесь выравнивание по времени сжатия.

Постепенно я пришел к выводу, что такой вариант на самом деле несбалансированный, а по-настоящему сбалансированный вариант следующий.

2 Вариант. (неожиданный?)
Те же данные.
тексты ($text) будут сжиматься 40 сек и результат будет 20 Мб
архивы ($compressed) будут сжиматься плохо, поэтому берется алгоритм, который сожмет до 92 Мб, но за 4 сек!
Итоговый результат 20+92=112 Мб за 4+4=44 сек.
Одинаковой будет скорость "убирания" лишних Мб.
В случае текста (100 Мб - 20 Мб)/40 сек = 2 Мб/сек
В случае архивов (100 Мб - 92 Мб)/4 сек = 2 Мб/сек
Такой вариант не будет тратить лишнего времени на сжатие трудносжимаемых данных.
При этом, правда, мы не получим "максимально возможного" сжатия. Но если оно нужно, можно его "впихнуть" в отдельный метод, допустим -mx.

Поскольку FreeArc и так обычно на больших данных обходит по степени сжатия WinRAR/7z, то потеря степени сжатия вряд ли будет критичной, но по скорости получится еще большее преимущество.

Добавлено:
Bulat_Ziganshin

По интерфейсу.
После сжатия я бы хотел, чтобы окно процесса (которое мы обсуждали) не закрывалось автоматически, а оставалось. А кнопка "Отменить" заменялась бы на "Закрыть".
Или это где-то уже есть в настройках? Я не нашел.

Цитата:

У меня 8gb ram так почему же FreeArc хочет использовать всего 2 гб?

потому что он ограничен макс. размером непрерывного блока памяти. в заголовке есть статья об этом ("....2 гб")


Цитата:

Может заменить в TotalCommander MultiArc plugin ANSI на UTF-8, а то с ANSI не распаковывает архив если в его пути есть русские имена?

а с utf-8 распаковывает? несколько лет назад этот плагин не держал utf-8, сделали наконец?

snkreg
А что на virustotal по этим файлам?

Engaged Clown
Инсталлер:
http://www.virustotal.com/file-scan/report.html?id=cff7c9a17ea707c7acd53c141bc1610a425456276b9021c06f4113043e810403-1314917160
SFX:
http://www.virustotal.com/file-scan/report.html?id=af6b3b57ed55f89de29ff2791162ef127f2a2ada71aff2c216e6a0ffd8bf5efa-1314916385

Предлагаю массово выяснить в чем дело, как минимум по касперу и ноду. Ибо это не троян, чтобы чистить постоянно, пусть вносят в исключения, это кощунство - детектить опенсорс софт...

Цитата:

потому что он  ограничен макс. размером непрерывного блока памяти. в заголовке есть статья об этом ("....2 гб")

Так макс блок можно расширить с помощью параметра IMAGE_FILE_LARGE_ADDRESS_AWARE. на 32bit - 3Gb а на 64bit вообще 4Gb. Почему вы не используете эту возможность???

Bulat_Ziganshin
Заметил, что в файлах i18n (во всех) пересекаются новые строки "0535 Processed" и "0536 Total" с уже существующими "lzma:1gb" и "ехе2"

vasulpr
вот при 4 гб адресного пространства размер макс. непрерывного блока будет как раз почти 2 гб

Добавлено:

Цитата:

Как дела с финальной версией ФА (0.70)? На оф. сайте висело сообщение что выйдет в декабре. В чем задержка?

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

В составе программы файл freearc.sfx (и не только он) постоянно определяется как Backdoor.Win32.SdBot.xgi http://www.bit.ly/p5yuoJ

Что делать?

kalpak
дело в том что сам по себе lzma может загрузить максимум 2 ядра. поэтому lzma/xlzma просто делит входные данные на блоки скажем по 16 мб и сжимает по несколько блоков одновременно

Shuld
1. уже сделано
2. http://freearc.org/history/changelog_full.htm - ищи --pause-before-exit

ruduk
второй раз уже про них забываю

написал сейчас касперам:


Цитата:

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

как я понимаю, нужно предоставить вам алгоритм распаковки архиватора?

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

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

Добавлено:

Цитата:

Не подскажете, как это сделать?

http://freearc.org/ru/FreeArc040-rus.htm#_Toc185595014

Bulat_Ziganshin
Та хватит новых фитч! Последняя бета достаточно стабильна чтобы стать финалкой.

На будущее: компилируйте ФА с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE чтобы потом вручную не прикручивать этот флаг.

Кто нибудь подскажет мне, какой самый сильный параметр сжатия в FreeArc , чтоб диски трещали

vasulpr

Цитата:

На будущее: компилируйте ФА с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE чтобы потом вручную не прикручивать этот флаг.

этот флаг там стоит давно-давнёшеньки, внимательней будьте

Bulat_Ziganshin
это я знал
просто почему память больше
с hc4/a0 чем с bt4 например:

Цитата:

4 потока hc4/a0 dictsize 16mb - 904
4 потока bt4/a1 dictsize 16mb - 621

4 потока hc4/a0 dictsize 32mb - 1800
4 потока bt4/a1 dictsize 32mb - 1168

это данные с диалогового окна 7zg
я проверял на практике
поэтому заметил, мне почему то кажется что a0/hc4
в 7z просит больше памяти потому
что он (a0) быстро выделяет память и не успевает ее освобождать
(я говорю именно о lzma2 в 7z)

Bulat_Ziganshin
Детектятся именно sfx модули, вовсе без архива, а sfx'ы, как я заметил, упакованы upx'ом - это, пожалуй, самый известный пакер PE файлов и невозможность его распаковать любым антивируником исключается. Сейчас большинство антивирусов умеют распаковывать даже не известные им пакеры/протекты используя виртуальную машину (типа универсального анпакера, который падает на хороших антиотладочных приемах, да и вообще от нестандартных инструкций, и тогда сообщает что этот файл suspecious packed и всякое такое). Но в данном случае просто распаковав эти sfx'ы и подсунув их в тот же virustotal, мы получим аналогичный результат - более 20 срабатываний! Вывод - в sfx модуле фриарка (именно в исходном машинном коде, а не созданном upx'ом сжатом файле) антивири находят штампы (маски байтов из антиирусной базы для поиска вредителей) от каких-либо других вреденосных объектов. Тут в любом случае надо обращаться к ведущим антивирусным организациям, чтобы они это дело пофиксили в своих детищах...ну или же менять свой код)

Действительно в последней версии стоит. Извините недосмотрел!Все претензии забираю.
Жду 0.70!

kalpak
потому что каждый процесс сжатия в hc4/a0 занимает один поток, а в bt4/a1 - два потока. поэтому в первом случае таких процессов создаётся 4, а во втором 2

R76LW90
-mx

Bulat_Ziganshin

Цитата:

а с utf-8 распаковывает?

Отлично распаковывает!

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

в этих условиях они детектят сам код распаковщика

Bulat_Ziganshin

2. http://freearc.org/history/changelog_full.htm - ищи --pause-before-exit

Нашел только один раз в версии 0,52 вот что
on – for "test" command in GUI mode
on-warnings – for other commands in GUI mode

И как это применять для GUI mode?

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

Так проблема в том, что они детектят как раз таки сам код распаковщика без какого либо .arc архива на хвосте.
Или я не понимаю что ты хочешь сказать..
Просто проверь свой sfx модуль на вирустотал.

Bulat_Ziganshin
понятно, спасибо
а многопоточный lzma2 в FreeArc будет реализован
через 4x4
и/или как в 7z?

Цитата:

P.S. Может заменить в TotalCommander MultiArc plugin ANSI на UTF-8, а то с ANSI не распаковывает архив если в его пути есть русские имена?

ок, внёс твой конфиг в сборку. кто ещё использует TotalCommander, плиз потестируйте с русскими, и каким-нибудь там китайско-арабскими именами файлов внутри архива этот конфиг: http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1142&limit=1&m=1#1

Добавлено:
Eagle1726
тебе сюда - http://forum.ru-board.com/topic.cgi?forum=5&topic=30239&glp

Shuld
FreeArc 0.52 alpha (July 27, 2009)
---------------------
Changes:
* Added option --pause-before-exit with the following settings:
on – always make a pause
off – never make a pause
on-warnings – make pause if there were any warnings due operation
on-error – if program exits due to error

* Default settings for the option:
off – for console mode
on – for "test" command in GUI mode
on-warnings – for other commands in GUI mode

kalpak
никак не будет реализован. lzma2 я сделаю для улучшения обработки несжимаемых данных, а многопоточные возможности, аналогичные lzma2, прекрасно реализуются и в 4x4