» FreeArc (часть 4)

Добрый день
Есть желание написать ebuild для freearc. Поэтому несколько вопросов отсюда
http://www.linux.org.ru/forum/general/7894692?lastmod=1340361987112#comment-7898078

dll работает. Но было бы не лишним реализовать поиск консольных декомпрессоров рядом с самой дллкой или arc.ini, а не в WINDOWS\System32, как сейчас происходит.

там банальная опечатка, я её уже поправил

Добавлено:
кстати, мы переехали на новый сервер, можно протестировать его скорость по http://freearc.org/download/refal.rar

Bulat_Ziganshin
Будь другом, подскажи.
Имеется образ ISO с игровыми файлами Wolfenstein2009 (не установка, а просто папка с игрой).
В "изначальном" репакерском установщике (который был упакован при помощи FreeArc) это всё ужато до 2,91 гига, но там настолько тупой установщик и структура подпапок, что я от него отказался в пользу своей сборки.
Теперь к вопросу.
Я хочу его максимально эффективно ужать, чтобы получить аналогичный размер, НО...
Так просто до такого размера ничего не получается ужать, там используется некий алгоритм PreComp с добавлением Srep.
Собственно, по синтасису я более менее разберусь (тем более, что с прошлого моего вопроса команда у меня осталась в заметках), а сейчас меня интересует вот что:
Я хочу (по твоему совету) промежуточные данные поместить на Ram-диск, но могу выделить на него не более 8 гигов (всё же ещё нужна память и для упаковки и для работы системы), и, следовательно вопрос: уместятся ли все промежуточные данные в 8 гигов при попытке сжатия плохожмущегося обычным способом 6-гигового файла?


з.ы.
Источник (в 3 частях) выглядит так:

FreeArc 0.67 (May 22 2012) listing archive: data1.bin

Archive type: FreeArc
Total bytes: 4,049,156,024
Compressed bytes: 1,127,225,672
Ratio: 27.8%

Directory blocks: 1
Directory, bytes: 59,107
Directory, compressed: 17,142
Solid blocks: 2
Avg. blocksize: 1931 mb

Compression memory: 4096 mb
Decompression memory: 4096 mb
Dictionary: precomp:4096mb+lzma:64mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 22 storing
31 4,049,156,024 1,127,225,672 1,439 precomp+srep:mem512m:m3f:a1:l512+lzma:64mb:normal:bt4:128
-----------------------------------------------------------------------------
1,461 files, 4,049,156,024 bytes, 1,127,225,672 compressed
All OK


FreeArc 0.67 (May 22 2012) listing archive: data2.bin

Archive type: FreeArc
Total bytes: 985,693,840
Compressed bytes: 976,175,484
Ratio: 99.0%

Directory blocks: 1
Directory, bytes: 802
Directory, compressed: 406
Solid blocks: 2
Avg. blocksize: 470 mb

Compression memory: 2542 mb
Decompression memory: 254 mb
Dictionary: lzma:254mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 2 storing
31 985,693,840 976,175,484 17 exe+delta+lzma:254mb:normal:bt4:128
-----------------------------------------------------------------------------
19 files, 985,693,840 bytes, 976,175,484 compressed
All OK


FreeArc 0.67 (May 22 2012) listing archive: data3.bin

Archive type: FreeArc
Total bytes: 976,277,188
Compressed bytes: 967,844,690
Ratio: 99.1%

Directory blocks: 1
Directory, bytes: 620
Directory, compressed: 378
Solid blocks: 2
Avg. blocksize: 466 mb

Compression memory: 2542 mb
Decompression memory: 254 mb
Dictionary: lzma:254mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 2 storing
31 976,277,188 967,844,690 13 exe+delta+lzma:254mb:normal:bt4:128
-----------------------------------------------------------------------------
15 files, 976,277,188 bytes, 967,844,690 compressed
All OK

Bulat_Ziganshin

Цитата:

кстати, мы переехали на новый сервер, можно протестировать его скорость по http://freearc.org/download/refal.rar

В один поток - 950кБ\с, а для несколько потоков файлик очень маленький.

Bulat_Ziganshin

Цитата:

я сделал вариант unarc.dll/sfx, который корректно работает с stdin-to-stdout фильтрами. у меня с srep работает. проверяйте:

unarc.exe x a1.arc
FreeArc 0.67 unpacker. Extracting archive: a1.arc
Extracting pdf.TAR.pcf (249562113 bytes)

ERROR: unsupported compression method srep:m3f:s250m

unarc.exe x a2.arc
FreeArc 0.67 unpacker. Extracting archive: a2.arc
Extracting pdf.TAR11.pcf (249562113 bytes)

ERROR: unsupported compression method srep

Bulat_Ziganshin

Цитата:

и ещё распаковку 32-битным srep

хотел добавить ещё проверку для
srep.exe
srep32.exe
так при проверке на подпорченном файле крашаться (неизвестно что будет, во время тестов), srep32i.exe отрабатывает нормально.

srep.exe
Инструкция по адресу "0x77c37000" обратилась к памяти по адресу "0x029e1000". Память не может быть "written".

srep32.exe
Инструкция по адресу "0x0040eb94" обратилась к памяти по адресу "0x02151000". Память не может быть "written".

ну, могу с тобой поделиться http://freearc.org/download/testdata/MsOfficeBCJ.7z

хотя мне и рефала хватило - 2 мбайт/с в одном потоке и 10 в 5 потоков

egor23
кстати, напиши свой тестовый скрипт. оставил на ночь вот такой:

@%*
@if errorlevel 1 time <nul >>u:\tester.log
@tester.cmd %*

tester.cmd srep -d 5g.srep-r nul

3 тыщи проверок по 5 гб = 15 тб данных не выявили проблем. однако, при распаковке этого файла используется всего 63 мб озу. и у меня возникло ещё одно интересное предположение - а что если сбой в srep происходит из-за необычно высокой нагрузки на блок трансляции адресов? обычные приложения используют озу довольно локально, а тут идут постоянно скачки по адресам. правда, тогда обычный rep с большим словарём точно также бы сбоил. вот, Егор, ещё один кандидат для тестов - его алгоритм мало чем отличается от srep, в конце концов



Цитата:

ERROR: unsupported compression method srep:m3f:s250m

arc.ini с описанием srep должен лежать в одном каталоге с unarc.exe

Добавлено:

Цитата:

при проверке на подпорченном файле крашаться

так в decompress нет никаких проверок, это у меня в to-do записано

и ещё - проверь распаковку в 2.91, там алгоритм был попроще, вдруг я наворотил что-то идеологически невыдержанное

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

это способ я думаю не будет лишним

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

Bulat_Ziganshin
ты и в правду странно себя ведёшь. я уверен, что ты получаешь уведомления об ПМ.
Если тебе начхать или ты считаешь это неважным, то может кто другой сможет помочь.

Цитата:

Булат, привет.
Я всё же насчёт иконок.
Откликнулся знакомый и попросил тз.
Я хотел попросить тебя его оформить - хотя бы что нужно, каких размеров, в каком количестве и в каком формате.
Мои мысли:
1. логотип - давай плясать от существующего - может он его глянет и что-нибудь подредактирует.
2. иконки - я думаю дать ему как наводку сравнение 3-ёх архиваторов как на форуме и темы для WinRar (http://www.rarlab.com/themes.htm) и 7zip (http://www.7-zip.org/logos.html).

От тебя нужно тз и может предложения или мысли если есть какие.

Спасибо.

или это тоже тролинг ?

kalpak,
FreeArc - это архиватор, а не искусственный разум да и думаю что бы это реализовать надо не хило времени.

Bulat_Ziganshin
Я думаю, лучше всего если вы cabal соберете, и выложите на hackage. Из кабала ебилдик я как-нибудь сделаю

Bulat_Ziganshin

Цитата:

arc.ini с описанием srep должен лежать в одном каталоге с unarc.exe

так лежит, более того ещё и пробывал прописывать путь к нему, не работает.

Цитата:

3 тыщи проверок по 5 гб = 15 тб данных не выявили проблем.

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

Цитата:

Запустил тест примерно в 7:00, поставил на паузу в 13:30, т.е. прошло 6.5часов, 1300 проходов.
В итоге получилось два сбойных прохода:
772_xcmd_split.TAR.pcf в 10:56
804_xcmd_split.TAR.pcf в 11:06

Цитата:

а на ночь поставить memtest гонять

memtest ничего плохо мне не сказал

Цитата:

я сделал вариант unarc.dll/sfx, который корректно работает с stdin-to-stdout фильтрами. у меня с srep работает. проверяйте:

кстати 2.95 в связке с arc.exe фигня получается, должен получится архив 74МБ, а получается 40МБ.

Добавлено:

Цитата:

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

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

Добавлено:

Цитата:

arc.ini с описанием srep должен лежать в одном каталоге с unarc.exe

нашёл причину, стоял пробел перед секцией:
пробел[External compressor:srep]
какой нежный unarc оказался

Цитата:

кстати 2.95 в связке с arc.exe фигня получается, должен получится архив 74МБ, а получается 40МБ.

причём в temp как раз создаётся файлик 74МБ, но на выходе получае 40МБ

Добавлено:

Цитата:

и ещё - проверь распаковку в 2.91, там алгоритм был попроще, вдруг я наворотил что-то идеологически невыдержанное

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

kalpak
подобная идея была немного в другом варианте - чтобы при перепаковке (команда ch) не перепаковывать неизменившиеся методы в начале цепочки. скажем, при перепаковке из rep:96m+lzma:64m в rep:96m+lzma:32m он распаковывал lzma:64m и затем направлял данные сразу на lzma:32m

На русском

Bulat_Ziganshin

Цитата:

и 10 в 5 потоков

поймал себя на мысли, что предел скорости у себя не увижу, нужен кто-нить у кого канал 1Гбит\с или более.

Что, правда такие слова есть в русском языке? Вы где учились, на Юпитере? ))))

я просто подумал раз есть псевдометод tempfile который просто говорит архиватору читать данные с темп-файла
то почему бы не указать что результат упаковки не сохранять непросто чтобы упаковать при прожорливости метода
а чтобы не ждать долго операции завергения внешнего(как это часто бывает с ГБ файлами precomp, ну и с 3,4[и >] гб файлами srep) а подложить уже готовенький файл

Bulat_Ziganshin

Цитата:

добавил, но тесты завтра утром планирую запустить

1000 проходов (распаковка srep и rar) ничего не дали

Цитата:

кстати, напиши свой тестовый скрипт. оставил на ночь вот такой:

[more=Читать дальше..]
[no]
cls
@echo off
color
setlocal enabledelayedexpansion
set /a nn=0
set /a DD=7
set bad_dir=c:\temp\bad\
set file_original=c:\temp\xcmd_split.TAR.pcf
set file=xcmd_split.TAR.pcf
set file_srep=xcmd_split.TAR.pcf.srep295_l64_a4
set srep32i=srep295_32i.exe
set srep32=srep295_32.exe
set srep=srep295.exe
:m1
set /a nn=%nn%+1
echo parts nn=%nn%
srep\%srep32i% -d -nomd5 %file_srep% %file% >>nul 2>&1
(md5sum\md5sum.exe -c md5\%file%.md5 >>nul 2>&1) & (IF ERRORLEVEL 1 (GOTO m2) else (del /F /Q %file% >>nul 2>&1) & GOTO m1)
:m2
set PP=SREP32i
set logs=%bad_dir%%DD%_logs_%nn%_%PP%
echo bad md5 PP=%PP% nn=%nn%
echo bad md5 PP=%PP% nn=%nn% >%logs% 2>&1
md5sum\md5sum.exe -b %file% >>%logs% 2>&1
(fc /b %file_original% %file% >>%logs% 2>&1)
xdelta\xdelta3.exe -0 -B 134217728 -W 16777216 -P 16777216 -I 0 -v -e -s %file_original% %file% %bad_dir%%DD%_diff_%nn%_%PP%_%file% >>%logs% 2>&1
del /F /Q %file% >>nul 2>&1
GOTO m1
[/no]
[/more]

Paramon111

Цитата:

Что, правда такие слова есть в русском языке? Вы где учились, на Юпитере? ))))

нажато
Цитата:

Сообщить модератору

подскажите а что он не умеет распаковывать просто перетаскиванием ?

4eLLka
из окна самой программы - нет. а вот перетаскивание правой кнопкой мыши в Explorer я сейчас делаю

Добавлено:
kalpak
реализовать это можно - извлечение промежуточных потоков и их вставку назад. просто это тоже такая второстепенная вещь. можно же на потоках подобрать оптимальную схему сжатия и затем сжать всё с нуля:

arc a a -m0 --nodir -dsgernp tempfile.1 files...
arc a a -m=precomp --nodir tempfile.2 tempfile.1
arc a a -m=srep --nodir tempfile.3 tempfile.2
arc a a -m=lzma --nodir tempfile.4 tempfile.3
...

и окончательное сжатие
arc a a archive files... -m=precomp+srep+lzma

Прошу прощения, вопрос (автору). Как автор одного из архивных плагинов под Far Manager (newarc) интересуюсь наличием исходного кода freearc.fmt. А поскольку newarc умеет несколько больше, интересуюсь также "где почесать" для извлечения файлов и их добавления во freearc архивы. Будет прекрасно, если средствами "чистого" кода или с помощью некой dll от freearc. Ну, если простые методы существуют. Или объяснят сложные.

Спасибо.

Архивировал 16 гб образ убунтовской виртуалки:

Код: 3 540 988 392  7z -mx -md256m
3 216 460 052  arc -mx (rep:1600m+lzma:177m)
2 980 064 981  srep + 7z -mx -md256m
2 956 691 497  srep + arc -m9x (lzma:254m)

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


Цитата:

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

а почему сразу по человечески сделать нельзя? чтобы ЛКМ и в нужную тебе папку

WARP_ItSelf
1. скачиваешь исходники 0.67 а ещё лучше берёшь с svn
2. читаешь readme.txt и настраиваешь среду компиляции

исходники fmt в каталоге Unarc, и для их компиляции достаточно c++, компилятор хаскела не нужен. там же есть код распаковки, можно поколдовать над исходниками чтобы добавить в fmt FreeArcExtract либо вызывать его снаружи из unarc.dll

для сжатия тебе понадобится freearc.dll. обращаться к ней несложно, но это 3 мб. такое устроит?

Добавлено:

Цитата:

1000 проходов (распаковка srep и rar) ничего не дали

это старый srep???

итак, мои результаты: дважды оставлял на пару часов srep 2.95. оба раза на первом часу было 1-3 сбоя, на втором портился дисковый кеш после чего естественно начинало сбоить на каждой распаковке

на ночь оставил srep 2.91, и он отработал без ошибок, за ночь разжав порядка 7->22 терабайта!!

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

vasulpr
потому что GUI основан на gtk, а там Drag&Drog вроде не очень работает
(может из за кроссплатформенности?)

Bulat_Ziganshin

Цитата:

это старый srep???

2.95, т.к. он не вызвал сбоев, то тестировать 2.91 бесмысленно.

Цитата:

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

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