Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: Bulat_Ziganshin
Дата сообщения: 26.09.2011 20:33
vishyakov
проще увеличить размер солид-блоков. а вообще ничего удивительного. есть такое эмпирическое правило - если тебе удалось улучшить сжатие, значит ты в чём-то ошибся . хотя изредка оно всё же не срабатывает
Автор: egor23
Дата сообщения: 27.02.2011 23:14
srep295.exe -d -mem128m -vmfile=vmfile_temp Nero-9.2.6.0_trial.tar.srep294_m3f_a4 - | 7z.exe x -si -ttar

Ratio: 1974371328 -> 506371254: 25.65%. Cpu 94.158 mb/sec, real 28.186 mb/sec. Matches 0 15102 286644, I/Os 0, RAM 0/88, VM 0/320, R/W 1160/1160

Everything is Ok

Folders: 57
Files: 1052
Size: 1973508786
Compressed: 568320

работает
Автор: Shuld
Дата сообщения: 12.06.2012 21:47
Bulat_Ziganshin

Цитата:
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).

Под последние версии архиватора, arc.ini я модифицировал, но не довел до конца (нужно много времени на проверки). Поэтому не выкладывал.
Первые методы из серии -m8. выглядят так:
81 = rep:1gb:64:c32+xtor:3:4m:h64k
82 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h512k:l4
83 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h1m:l8
84 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h8m:l8
и пока все.
Автор: egor23
Дата сообщения: 28.02.2011 01:46
Bulat_Ziganshin
ну вот приехали
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data

s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8

Добавлено:

Цитата:
ну вот приехали
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data

s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8

s-so123_512.srep распакован версией 0.8
при повторной попытке c srep295.exe распаковка прошла удачно
Автор: vishyakov
Дата сообщения: 29.09.2011 14:07

Цитата:
проще увеличить размер солид-блоков

это приведёт к соответствующим осложнениям при распаковке, особенно файлов по-одиночке. А то, о чём я говорил - нет.
Автор: Bulat_Ziganshin
Дата сообщения: 12.06.2012 22:05

Цитата:
через -m5p размер не уменьшается.

блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"


Цитата:
Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия.

запорожец - дикий тормоз на фоне бугатти, несмотря на те же 4 колеса


Цитата:
С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию.

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


Цитата:
В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.  

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


Цитата:
Кстати, попробовал packMP3 от создателя pacjJPG, действительно сжимает до 25%. Неплохо бы его тоже включить в FreeARC. mp3zip тоже хорош.

или как вариант - packARC. с precomp проблема в том, что jpeg-поддержка в нём иногда виснет, не знаю как с этим будет в packARC. mp3zip - коммерчески

Shuld
в общем тот, кому хочется это видеть в fa, должен будет взять arc.ini от июньской версии, добавить туда аккуратно твои методы и кинуть мне
Автор: egor23
Дата сообщения: 28.02.2011 14:26
Bulat_Ziganshin
Подопытный s-so123.tar 22427МБ, srep295_x64.exe

Упаковка
Compression ratio: 23516088832 -> 13137073412: 55.86%. Cpu 21.334 mb/sec, real 16.087 mb/sec -m1f -a1
Compression ratio: 23516088832 -> 13137263784: 55.87%. Cpu 38.879 mb/sec, real 24.641 mb/sec -m1f -a4

[more=Лог..]

timer.exe srep295_x64.exe -m1f -a1 s-so123.tar s-so123.tar.srep295_m1f_a1_l512

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1403 mb, -m1f -l512 -c512 -a1
Compression ratio: 23516088832 -> 13137073412: 55.86%. Cpu 21.334 mb/sec, real 16.087 mb/sec
Second pass: 100%

Kernel Time = 94.406 = 00:01:34.406 = 4%
User Time = 1405.250 = 00:23:25.250 = 65%
Process Time = 1499.656 = 00:24:59.656 = 69%
Global Time = 2152.750 = 00:35:52.750 = 100%


timer.exe srep295_x64.exe -m1f -a4 s-so123.tar s-so123.tar.srep295_m1f_a4_l512

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1595 mb, -m1f -l512 -c512 -a4
Compression ratio: 23516088832 -> 13137263784: 55.87%. Cpu 38.879 mb/sec, real 24.641 mb/sec
Second pass: 100%

Kernel Time = 99.218 = 00:01:39.218 = 6%
User Time = 904.062 = 00:15:04.062 = 54%
Process Time = 1003.281 = 00:16:43.281 = 60%
Global Time = 1648.062 = 00:27:28.062 = 100%
[/more]

Распаковка
srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp -s s-so123.tar.srep295_m1f_a1_l512 nul
Ratio: 23516088832 -> 13137548864: 55.87%. Cpu 154.378 mb/sec, real 39.751 mb/sec. Matches 0 12626 120042, I/Os 0, RAM 0/1759, VM 0/1568, R/W 2752/2752

srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp -s s-so123.tar.srep295_m1f_a4_l512 nul
Ratio: 23516088832 -> 13137759232: 55.87%. Cpu 155.478 mb/sec, real 44.838 mb/sec. Matches 0 9531 124168, I/Os 0, RAM 0/1759, VM 0/1504, R/W 2600/2600

Добавлено:
Bulat_Ziganshin
для -m1 многопоточность сделать возможно?
Автор: Bulat_Ziganshin
Дата сообщения: 29.09.2011 14:09
новая альфа:GUI: option to show/hide hidden files (Hidden/System on Windows and ".*" on Linux) and Ctrl-H key toggling the option
CUI: at the end of program execution, prints "\n" even on Windows
CLS: implemented CLS_INIT/CLS_DONE and cls-*.dll unloading when unarc.dll is unloaded
CLS: pass all parameters to the cls-*.dll, delimiting them with ':' as usual
CLS: now supports execution in directories with non-Latin1 names (and non-Latin1 method names too)
unarc.dll: added encryption support
unarc.dll: in the case of error/UserCancel, wait for all decompression threads to be finished before returning from FreeArcExtract()
unarc.dll: Addons\Unarc-DLL directory now contains readme-rus.txt describing dll usage and examples written in C++/Delphi/InnoSetup
unarc.dll: a lot of changes in FreeArcExtract() callbacks, see readme-rus.txt for details
arc.ini: improved bzip2 support
GUI: опция для показа/скрытия невидимых файлов (с атрибутом Hidden/System в Windows или именами ".*" в Linux) и кнопка Ctrl-H, переключающая эту опцию
CUI: в конце работы печатает "\n" - теперь и в Windows тоже
CLS: реализованы вызовы CLS_INIT/CLS_DONE, cls-*.dll выгружаются перед выгрузкой unarc.dll
CLS: в фильтр передаются все параметры, с разделением как обычно ':'
CLS: теперь cls-фильтры могут загружаться из каталогов с русскими (куитайскими...) именами и могут сами иметь русские имена
unarc.dll: поддержка зашифрованных архивов
unarc.dll: в случае экстренного выхода (при ошибке или по нажатию Cancel) ждёт завершения всех тредов распаковки перед возвратом из FreeArcExtract(), советую выводить в это время на экран что-то вроде "Отмена распаковки..." поскольку это может продолжаться несколько секунд
unarc.dll: каталог Addons\Unarc-DLL теперь содержит readme-rus.txt, описывающий использование dll, и примеры на C++/Delphi/InnoSetup
unarc.dll: множество изменений в колбеках FreeArcExtract(), см. readme-rus.txt
arc.ini: улучшена поддержка bzip2
Автор: Engaged Clown
Дата сообщения: 28.02.2011 14:41
Позволил себе наглость поправить шапку.
Что сделал:

1) Добавил тему по Rep и Srep. Шапка там включена, можно развить тему.
2) Добавил в архиваторы PowerArchiver и HaoZip.

Backup под

Версия для ОС Linux:

инсталлятор
[/more]

2
[more=FAQ по FreeArc]Q: (консольная версия) Как мне распаковать архив не в текущий каталог, а в заданный?
A: Воспользуйтесь параметром -dp=каталог.

Q: (консольная версия) Как использовать параметр -ag для автогенерации имени архива?
A: Пример:arc a -ag%Y%m%d MyArc_.arc *.txt --> MyArc_20091020.arc
Полный список опций можно посмотреть тут - Автоматическая генерация имени архива

Q: Есть ли поддержка многотомности (разбиение архива на части)?
A: Пока нет, но планируется. Дешёвая и сердитая реализация типа 7-zip'овской признана нецелесообразной.

Q: Я пользуюсь precomp прямо в FreeArc (кто не понял FreeArc сразу сжимает с подключением к сжатию precomp) Так вот чтобы потом архив распаковать надо какието параметры писать и файлики лополнительные.
A: Файлы - каталог max из freearc power pack. эти файлы должны быть во время упаковки в текущем каталоге или каталоге, доступном по PATH, за исключением arc.ini, который должен лежать в c:\
Если это сделать, то обычный скрипт распаковки freearc архивов всё как надо сделает. Но при этом у тебя будет кривой прогресс-бар и окошко precomp будет светиться на экране

Q: Хочу распаковать архивы в подкаталоги перед упаковкой в arc чтобы добиться максимального сжатия
A: Готовый батник для этого здесь

Q: Поддерживает ли зашифрованные архивы SFX/unarc.exe/unarc.dll?
A: Да, в альфа версии 0.67

Q: Возможно ли в arc реализовать запуск файла из архива после распаковки этого архива?
A: freearc-installer.sfx извлекает архив во временный каталог, запускает setup.exe и после его выполнения стирает все временные файлы. freearc-installer-nodelete.sfx делает то же самое кроме стирания[/more]

3
[more=Почему он сжимает лучше и быстрее, чем 7-zip/rar...] Почему он сжимает лучше, чем 7-zip/rar: поддерживаются алгоритмы lzma, ppmd и multimedia-сжатие с автоматическим выбором подходящего алгоритма по расширению файла
для улучшения сжатия используются фильтры dict (словарная замена), rep (находит повторы на расстоянии до 1Гб), delta (улучшает сжатие таблиц в бинарных файлах), bcj (EXE-фильтр), lzp (устраняет повторы в текстовых файлах)
в режиме максимального сжатия алгоритмы сжатия работают не параллельно, а последовательно, выгружая промежуточные данные на диск, что позволяет каждому из них использовать весь объём ОЗУ компьютера
если вам мало встроенных алгоритмов - вы можете использовать внешние: от препроцессора сжатых данных precomp до алгоритмов максимального сжатия ccmx/lpaq/durilca/uda/paq
плюс к этому производится интеллектуальная сортировка файлов, группирующая вместе одинаковые/похожие файлы и различные версии одного и того же файла
Почему быстрее упаковывает: для текстовых файлов используется ppmd, который работает куда быстрее чем lzma
использование фильтров уменьшает размер фактически сжимаемых данных
в быстрых режимах сжатия (-m1/-m2) используются специально разработанные быстрые алгоритмы - tornado и grzip
чтение сжимаемых данных идёт параллельно сжатию в специальный большой буфер, поэтому задержки дисковых операций не сказываются на процессе упаковки[/more]

4
[more=Результаты тестов, подтверждающие его крутизну...]

обсуждение на форуме www.compression.ru

Тестирование maximumcompression.com на 46 типах файлов (510 файлов, 301 Мб). FreeARC 0.51 занял первые 4 места по эффективности из 246 тестировавшихся архиваторов+режимов!
SqueezeChart 2009
Monster of compression 2009 (MOC 2009)
Squxe Archivers Chart (2007)[/more]

5
[more=Что подразумевается под "интеграцией с Explorer"]родные виндовые диалоги выбора файлов/каталогов (реализовано в 0.51)
контекстное меню на архивах .arc и других файлах, а также каталогах, с возможностью сделать его каскадным и выбором из большого набора команд (реализовано в 0.52)
отображение стандартного контекстного меню эксплорера в самом FreeArc
отображение иконки файла в списке файлов и диалоге перезаписи файла
колонка "тип файла", отображающая описание типа, полученное от Windows
drag&drop между freearc и explorer, а также между двумя экземплярами FreeArc
кнопка "фоном" должна минимизировать диалог прогресса в system tray[/more]
===== конец СПИСКА МОРЕЙ =====[/#]
[/#]
Автор: muzf
Дата сообщения: 12.06.2012 23:06

Цитата:
Цитата:
через -m5p размер не уменьшается.  

блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"

Всё равно не получается. Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9%
У packjpg выше приводил 79%.
И самое главное, до того как пробовать через консоль включал галочки на precomp jpeg в gui с тем же нулевым результатом (то есть на выходе были те же 98%, которые я считаю ошибкой на фоне packjpg).
Кстати, packjpg консольный уже полгода как версии 2.5, в dll же 2.4.


Цитата:
может, ещё зафигачить по умолчанию методы, требующие 100 гб озу для распаковки?

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

Кстати, очень хотелось бы видеть в документации пример запуска для режима backup с синхронизацией, то есть новые или изменившиеся файлы добавлялись бы в архив, а исчезнувшие файлы соответственно удалялись. Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.
Автор: vasulpr
Дата сообщения: 29.09.2011 14:33

Цитата:
новая альфа:

надеюсь к финальной версии осталось немного!

PS: Спасибо за двуязычную историю изменений!
Автор: egor23
Дата сообщения: 28.02.2011 16:49
Bulat_Ziganshin

Цитата:
-mem100: Cpu 76.815 mb/sec, real 54.448 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760

хи, получается ~100ГБ total R/W HDD
Автор: QSQ
Дата сообщения: 12.06.2012 23:15
о чём здесь дискуссия? я выбрал в раскрывающихся списках нужные мне настройки: этого недостаточно?
Автор: andhunt
Дата сообщения: 28.02.2011 22:57
Кто сможет помочь за отдельную плату осуществить такое в архиваторе?

можно сделать следующее в FreeArc.

в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:
1. setup.exe
2. primer.exe
3. primer.txt

я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?
Автор: kalpak
Дата сообщения: 29.09.2011 15:06
Profrager
а precomp оригинальном системные функции запускались напрямую с kernel32/msvcrt?
или так же с packJPG.dll, если нет, то как ты их перенаправил в dll без модификации precomp.exe ?

я к чему все это, к тому что раз cls-precomp использует объекты синхронизации и packJPG подменный чтобы распаковывать "налету"
может как то можно их и упаковывать, потому как при работе прекомпа фал постепенно увеличивает размер (хотя дома та же версия программы ведет себя по-другому, имея размер 0 байт все время перед окончанием)
Автор: Bulat_Ziganshin
Дата сообщения: 12.06.2012 23:25

Цитата:
Всё равно не получается.

возьми portable версию, распакуй в отдельный каталог и прям в каталоге с arc.exe проверни это


Цитата:
Кстати, packjpg консольный уже полгода как версии 2.5, в dll же 2.4.  

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


Цитата:
Но если эти методы такие замечательные что на них проводятся тесты и рекомендуются в этой ветке именно они, то почему бы и нет

это личное дело Shuld что он тестирует и советует - для 90% пользователей оно подходит, а для оставшихся 10% (которым иногда нужно распаковывать на меньшем озу) оно категорически неприемлемо


Цитата:
Идея пресетов позволит менять внутренние параметры от версии к версии, скрывая подробности от неопытных пользователей.

это в fa с самого начала - юзеры пишут -m1..-m9, а программа сама расшифровывает в силу текущего момента и параметров компа юзера


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

и навороченный fa не умеет. используй простенький 7-zip

QSQ
??? дискуссия о многом
Автор: V2driver
Дата сообщения: 01.03.2011 03:11
andhunt сколько $?
Автор: Vladimyr
Дата сообщения: 01.10.2011 12:03

Цитата:
множество изменений в колбеках FreeArcExtract
->

множество изменений в вызовах FreeArcExtract

это ж вроде по-русски
Автор: Bulat_Ziganshin
Дата сообщения: 01.03.2011 08:35
V2driver
и ты туда же? нельзя молча игнорировать тролля?
Автор: vasulpr
Дата сообщения: 13.06.2012 07:52
Bulat_Ziganshin
что за packARC ? это что ваша новая разработка?


Цитата:
это не даёт избавляться от дубликатов

так эти файлы затем по верху можно закатать lzma или rep-ом и все повторы исчезнут


Цитата:
дело в том, что использовать packjpg не очень удобно, поскольку он сжимает по одному файлу...и требует много времени на его запуски

фиг с тем временем упаковки, а розпаковну можно сделать параллельной, что ускорит ее немного
Автор: Pasha_ZZZ
Дата сообщения: 01.10.2011 12:27
Vladimyr
Цитата:
множество изменений в вызовах FreeArcExtract
Вызов - это вызов. Колбек - это обратный вызов, типа события.
Автор: slech
Дата сообщения: 01.03.2011 09:13
Bulat_Ziganshin
а почему троля ?
ты сам говорил о поддержке проекта.
Автор: kalpak
Дата сообщения: 03.10.2011 08:51
Bulat_Ziganshin
а CLS_DONE точно вызывается?
у меня что то не пишет нечего

я добавил вот эти строки в simple_codec.cpp

Код:     case CLS_INIT:
        {
            printf("\nInit sample cls\n");
            break;
        }
    case CLS_DONE: //printf("Params: %s",param);
        {
            printf("\nDone sample cls\n");
            break;
        }
Автор: muzf
Дата сообщения: 13.06.2012 09:30

Цитата:
Цитата:
Всё равно не получается.  

возьми portable версию, распакуй в отдельный каталог и прям в каталоге с arc.exe проверни это

Один в один, ini ведь тот же.
Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9% против 78% у packjpg

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

и навороченный fa не умеет. используй простенький 7-zip

Неплохо бы добавить такой режим в freearc, первоначально он меня заинтересовал фразой Solid compression with smart updates (only changed solid blocks are recompressed) , подумал что такое там уже есть. Но вижу, что в roadmap это запланирован в 2.0
Автор: CDK
Дата сообщения: 01.03.2011 09:36
Попробовал freearc-installer.sfx. Он при запуске начинает тупо распаковывать в temp без каких либо запросов. Попробовал с -s0 (по аналогии с -s2) - тогда уже не запускает в конце setup.exe. Я так понимаю что вариант с запросом куда распаковать не предусмотрен или дело не в лыжах?
ЗЫ: чего-то я rtfm никакого по freearc-installer.sfx не нашел
Автор: Bulat_Ziganshin
Дата сообщения: 13.06.2012 13:08

Цитата:
что за packARC ?

http://encode.ru/forums/2-Data-Compression


Цитата:
так эти файлы затем по верху можно закатать lzma или rep-ом и все повторы исчезнут

не предусмотрено в нынешней архитектуре fa. хотя наверно придётся делать, поскольку это стало актуально для многих ММ компрессоров, у wav/bmp файлов в точности та же проблема

Edit: добавил как http://code.google.com/p/freearc/issues/detail?id=307


Цитата:
фиг с тем временем упаковки, а розпаковну можно сделать параллельной, что ускорит ее немного

это опять же кому-то надо делать


Цитата:
Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9% против 78% у packjpg

у меня получается:[more]C:\>arc a a 0_68532_abbda6f_orig.jpg -m9j
FreeArc 0.67 (May 22 2012) compressing 1 file, 7,396,133 bytes. Processed 0%
Compressing 7,396,133 bytes with precomp042 -c- -intense -o$$arcpackedfile$$.tmp $$arcdatafile$$.tmp

Precomp v0.4.2 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2011 by Christian Schneider

Input file: $$arcdatafile$$.tmp
Output file: $$arcpackedfile$$.tmp

Using PACKJPG.DLL for JPG recompression.

--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg

100.00% - New size: 5955338 instead of 7396133

Done.
Time: 5 seconds, 86 milliseconds

Recompressed streams: 1/1
JPG streams: 1/1

You can speed up Precomp for THIS FILE with these parameters:
-d0

Errorlevel=0

Compressing 5,955,351 bytes with srep -m3f -mem256mb $$arcdatafile$$.tmp -
SREP 3.0 (January 30, 2012): input size 5 mb, memory used 33 mb, -m3f -l512 -c256 -a4
100%: 5,955,351 -> 5,955,395: 100.00%. Cpu 182 mb/s, real 122 mb/s
Second pass: 100%

Errorlevel=0
Compressed 1 file, 7,396,133 => 6,036,251 bytes. Ratio 81.6%
Compression time: cpu 0.86 secs, real 5.85 secs. Speed 1,265 kB/s
[/more]


Цитата:
ini ведь тот же.

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


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

--sync

я тебя сначала неправильно понял - решил что речь про антифайлы, как у 7-zip. вообще хорошая идея - добавить в доку раздел об использовании arc для бэкапа

Edit: добавил как http://code.google.com/p/freearc/issues/detail?id=306
Автор: Bulat_Ziganshin
Дата сообщения: 01.03.2011 12:07
CDK
1. а зачем там спрашивать? идея именно в том, чтоб предоставить распакованные файлы для setup.exe, а он уж дальше как нужно разбросает. и вообще лучше использовать IS
2. rtfm нет поскольку в нём нечего описываать
Автор: Profrager
Дата сообщения: 03.10.2011 17:38
kalpak
Цитата:
а precomp оригинальном системные функции запускались напрямую с kernel32/msvcrt?
или так же с packJPG.dll, если нет, то как ты их перенаправил в dll без модификации precomp.exe ?
напрямую с kernel/msvcrt. Когда загружается моя подставная дллка, она правит ссылки на системные функции в основном ехешнике, и перенаправляет на свои. По идее подобным образом можно сделать универсальный cls фильтр для любого пакера/анпакера, с единственным условием, что он не будет использовать fseek (или SetFilePointer). Или по крайней мере не перемещать указатель вне буфера cls фильтра (~несколько мегабайт). precomp отличается от обычных пакеров, т.к. он может патчить свое распакованное добро парой байт далеко за сотней мегабайт сзади.


Цитата:
я к чему все это, к тому что раз cls-precomp использует объекты синхронизации и packJPG подменный чтобы распаковывать "налету"
может как то можно их и упаковывать,
можно, конечно, но это надо расбираться и с сжимающей частью программы. Для меня эффективность упаковки по времени не интересна.


Цитата:
а CLS_DONE точно вызывается?
у меня что то не пишет нечего
CLS_DONE вызывается в самом конце, перед завершением процесса (по крайней мере в unarc.dll так). Попробуй MessageBox поставить вместо printf, авось покажется.
Автор: egor23
Дата сообщения: 01.03.2011 12:11
Bulat_Ziganshin

Цитата:
так дело именно в том, что проблемы возникают у одного из 10.000. если б проблемы были у большинства - всё было б ясно, а так они оказываются в дураках


Цитата:
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data

Мысля:
Проблема в том что данные получаются битые? или в том что подсчёт md5 сбоит?
можно для тестирования сделать билд, который не прерывает распаковку?
Автор: Bulat_Ziganshin
Дата сообщения: 01.03.2011 12:53
slech
тролль - потому что повторяет своё сообщение, разве не очевидно? соответственно, помогая таким людям, вы может и улучшите своё материальное положение, но способствуете засиранию темы и превращению её в такой же отстойник как и темы по is, рекомпрессии и пр.

Engaged Clown
имхо лучшая тема по srep - та, в которой никак не упоминается его название. иначе и в неё набегут пионеры


Цитата:
можно для тестирования сделать билд, который не прерывает распаковку?

-nomd5

Добавлено:

Цитата:
7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.
тогда не мешало бы и кнопку извлечь переделать, а то какой то плейер получается


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


Цитата:
Цитата:
разобрался. ты напоролся на известную багу в arc - если в архиве arc можно найти несжатый архив другого формата, то он откроет именно внутренний архив:

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


если он не упакуется, то извлечь можно будет с помощью 0.60 или убрав 7z.dll из каталога программы


Цитата:
хм, а как же создание архива ARC без пробелов в имени и успешном листинге ?

случайное совпадение. от версии архиватора зависит, ибо 0.666 сжимает несколько иначе, сохраняя as-is несжавшиеся блоки

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.