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

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

Автор: sabio
Дата сообщения: 30.05.2010 14:31
батник для "более плотного" сжатия директорий
запускать из директории, которую надо заархивировать
сначала он обойдёт её рекурсивно, распакует архивы, указанные в REPACK, в одноимённые папки и удалит оригиналы (при этом "архивы в архивах" также будут распакованы)
потом сожмёт всё содержимое директории в одноимённый архив с указанными в ARC_OPTIONS параметрами


Код:
@echo off

set ARC_OPTIONS=-mx

set REPACK=*.zip;*.rar;*.tar;*.gz;*.arc;*.7z

call :unpack_all %CD%

echo.

for /D %%D in (.) do set ARC_NAME=%%~nxD
arc a -r %ARC_OPTIONS% "..\%ARC_NAME%.arc" *

goto :eof


:unpack_all
for /R "%~1" %%F in (%REPACK%) do (
if not exist "%%~dpnF" (
echo Unpacking %%F...
md "%%~dpnF"
arc x -dp"%%~dpnF" -- "%%F" >nul
if errorlevel 1 (
echo [ERR] Error unpacking %%F
rd /s /q "%%~dpnF"
) else (
del "%%F"
call :unpack_all "%%~dpnF"
)
) else (
echo [WRN] Folder %%~dpnF exists already - cannot unpack %%F
)
)
Автор: Sig666
Дата сообщения: 30.05.2010 14:49
Engaged Clown
Число не хорошее
Автор: sabio
Дата сообщения: 30.05.2010 14:50
Bulat_Ziganshin
может, не совсем явно было написано сразу..
если делать архив так: arc a ..\test.arc .
то архив создаётся нормально (Far, например, показывает всё его содержимое), но FreeArc GUI в нём показывает только одну строку с "точкой"
Автор: Engaged Clown
Дата сообщения: 30.05.2010 15:00
Sig666
Сейчас багрепорты только по существу принимаются, не думаю что кто-то будет смотреть версию почти годичной давности.
Автор: Bulat_Ziganshin
Дата сообщения: 30.05.2010 15:05

Цитата:
если делать архив так: arc a ..\test.arc .

http://code.google.com/p/freearc/issues/detail?id=215


Цитата:
не думаю что кто-то будет смотреть версию почти годичной давности.

так проблема ведь в unarc.dll от 0.60

Sig666
у меня в FreeArc4InnoSetup3_5.zip есть готовый exe-шник инсталятора. с ним твой архив распаковывается?
Автор: Sig666
Дата сообщения: 30.05.2010 15:54
Bulat_Ziganshin
Ага, ваш инсталлятор распаковывает. Видимо проблема в том, что у меня unicode Inno Setup... Скомпилировал с ansi версией и проблем не возникло.
Автор: sabio
Дата сообщения: 30.05.2010 16:11
промазал топиком - перенёс в топик по FreeArc+Unix
Автор: troyan90
Дата сообщения: 30.05.2010 18:32
я может быть жутко туплю но не как не соображу какой коммандой из архива извлечь один файл
в хелпе нашел это

Цитата:
x - Извлечь файлы из архива с полными путями

и это

Цитата:
е - Извлечь файлы из архива в текущий каталог


мне нужно всего один файл извлечь. какие параметры использовать?
Автор: immortal223
Дата сообщения: 30.05.2010 20:25
Как его подключить в тОтал коммандер?
Автор: slech
Дата сообщения: 30.05.2010 21:01
troyan90

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


Usage: Arc command [options...] archive [files... @listfiles...]



arc e bin.arc -dpD:\Test 7zG.exe


Добавлено:
кстати у меня arc подвис на:

Цитата:

D:\Test\FreeArc\bin>arc e bin.arc 7zG.exe
FreeArc 0.666 extracting archive: bin.arc
Extracting 1 file, 226,304 bytes. Processed 0%
Overwrite 7zG.exe?
(Y)es / (N)o / (A)lways / (S)kip all / (U)pdate all / (Q)uit? n
0%arc: ArcExtract.hs109,43)-(113,15): Non-exhaustive patterns in lambda

0%


Добавлено:
проблема наблюдается при ответах:
(N)o / (S)kip all / (U)pdate all
Автор: troyan90
Дата сообщения: 30.05.2010 21:16
slech
спасибо
Автор: Bulat_Ziganshin
Дата сообщения: 31.05.2010 10:15

Цитата:
Как его подключить в тОтал коммандер?

найди файл freearc.addon и прочитай. или просто импортируй этот файл в MultiArc plugin

troyan90
ещё может помочь ключ -fn


Цитата:
проблема наблюдается при ответах:
(N)o / (S)kip all / (U)pdate all

http://code.google.com/p/freearc/issues/detail?id=217
Автор: CDK
Дата сообщения: 31.05.2010 15:11
тут три страницы назад проскакивало:

Цитата:
ты путаешь разные вещи - общий объём доступной памяти и наибольший непрерывный кусок. в любой винде 32-разрядным прогам доступны младшие 2 гига, но они фрагментированы всяческими dll. с параметром /3gb в boot.ini дают ещё гиговый кусок наверху, в 64-разрядной винде дают 2гиговый кусок, при этом в них отсутствуют всяческие dll, т.е. эти куски непрерывны

т.е. я правильно понимаю, что те 2042 Мб в Largest block которые я имею на 6 гигах + чистая Win 7 Ultimate x64 это предел на данный момент? или можно добиться 3-гигового куска?
Автор: Bulat_Ziganshin
Дата сообщения: 31.05.2010 15:13
CDK
да, предел. а зачем тебе больший кусок?
Автор: CDK
Дата сообщения: 31.05.2010 15:31
Bulat_Ziganshin
ну шоб сильнее жалось без использования внешних утилит типа srep

или алгоритму паковки больше 2 гигов память уже не нужна?
Автор: Bulat_Ziganshin
Дата сообщения: 31.05.2010 16:30
CDK
да, от доп. памяти может быть толк. но увы, сейчас это можно сделать только ручками

Добавлено:

Цитата:
батник для "более плотного" сжатия директорий

спасибо! в фак добавил


Цитата:
Ага, ваш инсталлятор распаковывает. Видимо проблема в том, что у меня unicode Inno Setup... Скомпилировал с ansi версией и проблем не возникло.

странно. там хотя бы не-английские буквы в именах файлов есть?
Автор: CDK
Дата сообщения: 31.05.2010 17:15

Цитата:
сейчас это можно сделать только ручками

вашими или нашими?

т.е. это надо править код или можно вынудить фриарк/винду взять/отдать кусок поболее?
Автор: Bulat_Ziganshin
Дата сообщения: 31.05.2010 17:44
CDK
код править не надо. сжатие улучшить можно, вручную конструируя спецификации сжатия. если ты прочтёшь доку и все 400 страниц этой темы, то может разберёшься как это делать

Добавлено:

Цитата:
вот пример игры Alpha Protocol папка весит 3,88 гига после прекомпа она весит 8 гигов после srep около 2 гигов

я правьно понял что это будет хороший вариант для hfcb? и не очень большой, и precomp и srep на нём отлично отрабатывают
Автор: Sig666
Дата сообщения: 31.05.2010 20:07

Цитата:
странно. там хотя бы не-английские буквы в именах файлов есть?

Ни одного.
Автор: Bulat_Ziganshin
Дата сообщения: 31.05.2010 20:25

Цитата:
Допустим Split Second на 90метров лучше жмётся 7zip'ом

какой словарь 7-zip? использовал ли ты dispack и большой словарь lzma в fa?
Автор: Bulat_Ziganshin
Дата сообщения: 01.06.2010 11:32
кол-во загрузок за март-май: 25-30-35k. правда, при 200 тысячах инсталяций за всю её историю, регулярно программой пользуется всего несколько тысяч человек. возможно, с появлением поддержки zip и прочего ситуация серьёзно изменится

Добавлено:
ха, я обнаружил что facompress*.dll были не запатчены iccpatch'ем. так что просьба к обладателям amd: загрузите новую dll и проверьте скорость сжатия в 3 режимах - вообще без dll, со стандартной dll и с новой. лучше всего проверять на grzip:m4, на нём разница наиболее заметна. текстовый файл для теста можно взять например как http://compressionratings.com/files/cr_txt1.exe (nanozip sfx)
Автор: PAQer
Дата сообщения: 01.06.2010 14:53
Bulat_Ziganshin

Цитата:
возможно, с появлением поддержки zip и прочего ситуация серьёзно изменится

очень сомневаюсь, если людям не нужен фриарк в данном виде, то zip, вряд-ли серьезно изменит ситуацию, его ведь и так читают все кому не лень. Надеюсь мои реквесты уже в todo?

Вот, кстати эпичный тест для dispack'a фриарковского:

Файлы - 14 dllок размером 6.5мб. В основном там код.
dispk - это консольный, а dispack фриарковский.

Код:
6.50 - оригинал без сжатия
6.06 - rep
4.75 - dispack+rep
3.92 - dispk+rep (ого!)

а теперь непосредственно сжатие (уже в кб результаты):

964 - exe+delta+lzma:10m:max
945 - dispack+delta+lzma:10m:max
933 - dispk+lzma:10m:max
767 - dispk+delta+lzma:10m:max !!!
703 - dispk+nz:cm:64m
699 - dispk+delta+nz:no2:64m (ассиметрик всяко лучше CM)
650 - dispk+delta+nz:cm:64m
для сравнения WinRK (rolz_3) ужал до 731кб, это говорит о том, что дизасм там юзается уже довольно давно (я вот не знал об этом).
Автор: Bulat_Ziganshin
Дата сообщения: 01.06.2010 15:32

Цитата:
Причем эффект именно от совокупности дельты и дизпака.

это может быть эффект одного конкретного файла. надо побольше тестов провести прежде чем делать глобальный вывод


Цитата:
Так почему бы не юзать готовый x86-парсер из PAQa?

что он делает, как его найти, есть ли он в zpaq?
Автор: Profrager
Дата сообщения: 01.06.2010 15:41
Bulat_Ziganshin


Цитата:
ха, я обнаружил что facompress*.dll были не запатчены iccpatch'ем. так что просьба к обладателям amd: загрузите новую dll и проверьте скорость сжатия в 3 режимах - вообще без dll, со стандартной dll и с новой. лучше всего проверять на grzip:m4, на нём разница наиболее заметна. текстовый файл для теста можно взять например как http://compressionratings.com/files/cr_txt1.exe (nanozip sfx)



AMD Phenom II X4 955

[more=Тест lzma & GRZip..]
Без facompress.dll


F:\1>arc a -lc- -mlzma:64mb:fast arc02.arc crtext1_100m
Compression time: cpu 21.22 secs, real 21.00 secs. Speed 4,761 kB/s
Compression time: cpu 21.05 secs, real 20.98 secs. Speed 4,765 kB/s
Compression time: cpu 21.14 secs, real 21.00 secs. Speed 4,761 kB/s


Со непропатченной facompress.dll 0,666


F:\1>arc a -lc- -mlzma:64mb:fast arc04.arc crtext1_100m
Compression time: cpu 20.03 secs, real 19.95 secs. Speed 5,011 kB/s
Compression time: cpu 19.86 secs, real 19.84 secs. Speed 5,039 kB/s
Compression time: cpu 19.98 secs, real 19.94 secs. Speed 5,015 kB/s



С пропатченной facompress.dll 0,666


F:\1>arc a -lc- -mlzma:64mb:fast arc01.arc crtext1_100m
Compression time: cpu 19.94 secs, real 19.94 secs. Speed 5,015 kB/s
Compression time: cpu 19.91 secs, real 19.94 secs. Speed 5,015 kB/s
Compression time: cpu 19.97 secs, real 19.97 secs. Speed 5,007 kB/s
Compression time: cpu 19.84 secs, real 19.81 secs. Speed 5,047 kB/s
Compression time: cpu 19.97 secs, real 19.94 secs. Speed 5,015 kB/s


Без facompress.dll


F:\1>arc a -lc- -mgrzip:m4 arc01.arc crtext1_100m
Compression time: cpu 11.64 secs, real 3.09 secs. Speed 32,323 kB/s
Compression time: cpu 11.56 secs, real 3.09 secs. Speed 32,323 kB/s
Compression time: cpu 11.67 secs, real 3.05 secs. Speed 32,821 kB/s
Compression time: cpu 11.69 secs, real 3.08 secs. Speed 32,487 kB/s
Compression time: cpu 11.75 secs, real 3.09 secs. Speed 32,323 kB/s


Со непропатченной facompress.dll 0,666


F:\1>arc a -lc- -mgrzip:m4 arc05.arc crtext1_100m
Compression time: cpu 6.70 secs, real 1.81 secs. Speed 55,172 kB/s
Compression time: cpu 6.69 secs, real 1.84 secs. Speed 54,237 kB/s
Compression time: cpu 6.80 secs, real 1.84 secs. Speed 54,237 kB/s
Compression time: cpu 6.91 secs, real 1.83 secs. Speed 54,701 kB/s
Compression time: cpu 6.95 secs, real 1.84 secs. Speed 54,237 kB/s


С пропатченной facompress.dll 0,666


F:\1>arc a -lc- -mgrzip:m4 arc01.arc crtext1_100m
Compression time: cpu 6.73 secs, real 1.83 secs. Speed 54,701 kB/s
Compression time: cpu 6.70 secs, real 1.81 secs. Speed 55,172 kB/s
Compression time: cpu 6.75 secs, real 1.81 secs. Speed 55,172 kB/s
Compression time: cpu 6.77 secs, real 1.81 secs. Speed 55,172 kB/s
Compression time: cpu 6.70 secs, real 1.84 secs. Speed 54,237 kB/s
Compression time: cpu 6.69 secs, real 1.83 secs. Speed 54,701 kB/s

[/more]
Автор: PAQer
Дата сообщения: 01.06.2010 15:51

Цитата:
это может быть эффект одного конкретного файла. надо побольше тестов провести прежде чем делать глобальный вывод

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


Цитата:
что он делает, как его найти, есть ли он в zpaq?

Он высчитывает позиции x86 блока (размер, оффсет) по заголовкам.
На счет zpaq хз, ну как с BMP - MM анализирует данные RAW, а paq по заголовкам вычисляет те же битмэпы/tga/wav/jpg внутри файла, так же и с x86. Я вообще не понимаю почему это только в paqe, исходники открыты, а даже в нанозипе нет. Либо сырой анализ (winrar/nanozip), либо вообще ничего.
Автор: Bulat_Ziganshin
Дата сообщения: 01.06.2010 16:47

Цитата:
Он высчитывает позиции x86 блока (размер, оффсет) по заголовкам.

неинтересно


Цитата:
исходники открыты

gpl
Автор: GhoSt_1616
Дата сообщения: 01.06.2010 19:31

Цитата:

Цитата: Допустим Split Second на 90метров лучше жмётся 7zip'ом

какой словарь 7-zip? использовал ли ты dispack и большой словарь lzma в fa?
Автор: Bulat_Ziganshin
Дата сообщения: 01.06.2010 19:36
GhoSt_1616
просто ты его готовить не умеешь
Автор: PAQer
Дата сообщения: 01.06.2010 19:42

Цитата:
C этим не ко мне, мы выяснили данную ситуацию вместе с товарищем cdman/ Репак мы делали одинаково, компы у нас мощные, он делал через 7zip, я - Фриарк.

Фриарк АПРИОРИ не может сжимать хуже, используется тот же lzma код что и в 7-zip'е, единственное отличие которое могло более менее повлиять, это отсутствие lzma2. А наличие во фриарке препроцессоров должно как минимум нивелировать разницу. Проще говоря CDman мог форсировать у lzma lc8, а ты нет, другой размер словаря (или матчфандер), больше не всегда лучше бывает, как это ни странно. В общем, учись сжимать с помощью фриарка. Хоть бы написали где фейл был, на каких данных и каков их размер, тогда бы было проще объяснить эту ситуацию.
Автор: Viewgg
Дата сообщения: 01.06.2010 22:39
PAQer

Цитата:
Фриарк АПРИОРИ не может сжимать хуже, используется тот же lzma код что и в 7-zip'е

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


Цитата:
единственное отличие которое могло более менее повлиять, это отсутствие lzma2

Да в сжатии между LZMA и LZMA2 вряд ли есть существенное отличие в большинстве случаев.

Bulat_Ziganshin

Цитата:
просто ты его готовить не умеешь

Ммм, так вроде фишка FA не в том, чтобы указать параметры типа -mx -ld<сколько надо>, а дальше прога сама разберется, я не прав?

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970

Предыдущая тема: Opera (часть 14)


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