» FreeArc (часть 4)

Позволил себе наглость поправить шапку.
Что сделал:

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]
===== конец СПИСКА МОРЕЙ =====[/#]
[/#]

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

Кто сможет помочь за отдельную плату осуществить такое в архиваторе?

можно сделать следующее в 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 должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

andhunt сколько $?

V2driver
и ты туда же? нельзя молча игнорировать тролля?

Bulat_Ziganshin
а почему троля ?
ты сам говорил о поддержке проекта.

Попробовал freearc-installer.sfx. Он при запуске начинает тупо распаковывать в temp без каких либо запросов. Попробовал с -s0 (по аналогии с -s2) - тогда уже не запускает в конце setup.exe. Я так понимаю что вариант с запросом куда распаковать не предусмотрен или дело не в лыжах?
ЗЫ: чего-то я rtfm никакого по freearc-installer.sfx не нашел

CDK
1. а зачем там спрашивать? идея именно в том, чтоб предоставить распакованные файлы для setup.exe, а он уж дальше как нужно разбросает. и вообще лучше использовать IS
2. rtfm нет поскольку в нём нечего описываать

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 сбоит?
можно для тестирования сделать билд, который не прерывает распаковку?

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

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


Цитата:

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

-nomd5

Добавлено:

Цитата:

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

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


Цитата:

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

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

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


Цитата:

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

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

Цитата:

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

можешь сформулировать требования для иконок ?
сколько и каких - давай искать платный вариант - сколько такое может стоить ?

а если всё же сначала попробовать поискать среди бесплатных?
http://habrahabr.ru/blogs/iconoskaz/114508/

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

Bulat_Ziganshin

Цитата:

-nomd5

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

нужно что-то наподобие http://www.7-zip.org/logos.html

slech
так есть же отдельная тема про логотип для FreeArc - вон её даже в шапку добавили
там и лежат все "нагенерированные пользователями" идеи

или о чём ты?

sabio
не совсем о логотипе, но может в той теме и продолжить.
речь о иконках интерфейса.

Цитата:

Here, memory-mapped files degrade -m2 performance even more

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

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



Цитата:

для меня выходом будет stdin/stdout но там сейчас не доделки, и хотелось бы чтобы у FreeArc\Arc\unarc был полноценный stdin/stdout.

да, я сейчас как рза над этим раюботаю. в самом srep stdin+stdout тоже что-то разладился с 18 февраля, надо разобраться


Цитата:

srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp

-vmfile можно не указывать, там по дефолту future-lz.tmp


Цитата:

для -m1 многопоточность сделать возможно?

при упаковке? уже естью у меня 4-ядерник до 40% нагружается

Bulat_Ziganshin

Цитата:

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

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

у мене така проблема

FA 0.666
win7 and winXP
уровень сжатия ультра с упорядочиванием файлов по расширению
3,25 Гб ОП
С свободно 4,82 Гб
D свободно 296Гб на этот проводится архивация

VasulNoz
чисти диск С: Не буду объяснять почему.

VasulNoz
в настройках программы установи tempdir на d:

Цитата:

так откуда я узнаю что сбой произошёл, если сбой связан с расчётом md5?

fc /b с оригиналом

Цитата:

или всё таки установленно, что данные получаются на выходе битые?

да. в общем, рассказываю, что у меня было: невозможно было вообще проверить, правильно ли работает srep, из-за того что при распаковке сыпались ошибки. думал, что это из-за большого числа I/O операций при обычной распаковке, но потом оказалось, что и распаковка future-lz без ограничений памяти сбоит

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

думал, что дело в разгоне, снял его - не помогло. тогда я наконец попробовал скопировать распаковываемый файл на другой винт - ошибки исчезли! затем на другой раздел первого винта - тоже всё ок. а лежал у меня файл на небольшом разделе, с которого я два года раздавал торренты. могу объяснить эффект только тем, что диск в этом месте "протёрся", хотя сбоит как-то странно - всякий раз в разных местах, да ещё при этом и кеш портит

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

для прикола - лог моих тестов (диск g - сбойный, напоминаю что srep создаёт врем. файл в тек. каталоге): [more=лог]F:\Temp>G:\f.cmd G:\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 315.115 mb/sec, real 148.644 mb/sec. Matches 16903 17275 101865, I/Os 0, RAM 470/632, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 301.439 mb/sec, real 268.311 mb/sec. Matches 16903 17275 101865, I/Os 0, RAM 470/632, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 296.611 mb/sec, real 259.126 mb/sec. Matches 13148 13520 101865, I/Os 0, RAM 291/459, VM 192/192, R/W 0/192
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 276.444 mb/sec, real 226.211 mb/sec. Matches 11208 11580 105105, I/Os 0, RAM 158/159, VM 368/576, R/W 384/752
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 G:\lp2.pcf.srep-r nul
Ratio: 335544320 -> 216895290: 64.64%. Cpu 294.645 mb/sec, real 224.164 mb/sec. Matches 2399 3548 6909, I/Os 0, RAM 32/59, VM 64/64, R/W 0/64^CЗавершить выполнение паке
тного файла [Y(да)/N(нет)]? y



G:\>G:\f.cmd F:\Temp\lp2.pcf.srep-r

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 287.307 mb/sec, real 185.588 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 274.860 mb/sec, real 163.288 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 292.157 mb/sec, real 104.050 mb/sec. Matches 4254 18705 190765, I/Os 0, RAM 156/459, VM 1440/1656, R/W 216/1656
ERROR! Checksum of decompressed data is not the same as checksum of original data

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 259.695 mb/sec, real 165.344 mb/sec. Matches 4893 12391 211440, I/Os 0, RAM 152/159, VM 1464/2136, R/W 1736/3200
ERROR! Checksum of decompressed data is not the same as checksum of original data

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 215.878 mb/sec, real 120.354 mb/sec. Matches 1026 8544 264278, I/Os 0, RAM 52/59, VM 1624/2360, R/W 4096/5720
ERROR! Checksum of decompressed data is not the same as checksum of original data



F:\Temp>G:\f.cmd F:\Temp\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 305.780 mb/sec, real 229.560 mb/sec. Matches 29409 31697 188028, I/Os 0, RAM 1382/1872, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 295.632 mb/sec, real 248.457 mb/sec. Matches 7637 27310 188028, I/Os 0, RAM 492/983, VM 952/952, R/W 0/952
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 285.963 mb/sec, real 202.580 mb/sec. Matches 4254 18705 190765, I/Os 0, RAM 156/459, VM 1440/1656, R/W 216/1656
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 234881024 -> 146617058: 62.42%. Cpu 307.273 mb/sec, real 102.757 mb/sec. Matches 2939 3548 6594, I/Os 0, RAM 80/107, VM 0/0, R/W 0/0^CЗавершить выполнение пакетн
ого файла [Y(да)/N(нет)]? y



U:\>G:\f.cmd U:\lp2.pcf.srep-r

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 277.883 mb/sec, real 198.049 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 264.975 mb/sec, real 176.744 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 248.717 mb/sec, real 155.206 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 U:\lp2.pcf.srep-r nul
Ratio: 2181038080 -> 1159031584: 53.14%. Cpu 265.293 mb/sec, real 143.418 mb/sec. Matches 6845 9046 87945, I/Os 0, RAM 128/159, VM 496/576, R/W 224/720^CЗавершить выпол
нение пакетного файла [Y(да)/N(нет)]? y



F:\Temp>G:\f.cmd F:\Temp\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 275.395 mb/sec, real 168.174 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 265.323 mb/sec, real 154.438 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 249.243 mb/sec, real 137.346 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 185.656 mb/sec, real 103.877 mb/sec. Matches 0 70888 2376056, I/Os 0, RAM 0/160, VM 0/2136, R/W 12120/12120

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 94.845 mb/sec, real 59.705 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760
[/more]

Bulat_Ziganshin

Цитата:

могу объяснить эффект только тем, что диск в этом месте "протёрся"

ну это проверить можно, виктория или т.п. Вам в помощь.
посмотрел s-so123_512.srep (повезло что ещё не заменил на новый), так там всё красиво с поверхностью.
так что если дело в HDD, то наверно не в поверхности дело.

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

3.
Цитата:

1. а зачем там спрашивать? идея именно в том, чтоб предоставить распакованные файлы для setup.exe, а он уж дальше как нужно разбросает. и вообще лучше использовать IS
2. rtfm нет поскольку в нём нечего описываать

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

Bulat_Ziganshin

Цитата:

могу объяснить эффект только тем, что диск в этом месте "протёрся"

решил проверить гипотезу, но на RAM-drive, все файлы "лежат" на RAM-drive:
RAM-drive 1200МБ
xcmd_split.TAR.pcf 933МБ
xcmd_split.TAR.pcf.srep295_l64_a4 110МБ
Методика:
делаем распаковку с -nomd5, после проверяется md5 полученного файла.
srep295.exe -d -nomd5 xcmd_split.TAR.pcf.srep295_l64_a4 xcmd_split.TAR.pcf

Что представляет из себя файлик - xcmd_split.TAR.pcf.srep295_l64_a4
srep295.exe -m3f -l64 -a4 xcmd_split.TAR.pcf xcmd_split.TAR.pcf.srep295_l64_a4
srep295.exe -d -nomd5 xcmd_split.TAR.pcf.srep295_l64_a4 nul
Ratio: 978388288 -> 114967199: 11.75%. Cpu 182.556 mb/sec, real 171.049 mb/sec. Matches 0 67098 3299595, I/Os 0, RAM 0/21, VM 0/0, R/W 0/0

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

fc /b w:\xcmd_split.TAR.pcf 772_xcmd_split.TAR.pcf
Сравнение файлов W:\xcmd_split.TAR.pcf и 772_XCMD_SPLIT.TAR.PCF
2D35B6E0: 00 CC
2D43A71B: 00 CC
2D4D0778: 00 CC
2DD8FAE9: 00 CC
2DD93038: 00 CC
2DD930E3: 00 CC
2DD9B49D: 00 CC
2DE50932: 00 CC

fc /b w:\xcmd_split.TAR.pcf 804_xcmd_split.TAR.pcf
Сравнение файлов W:\xcmd_split.TAR.pcf и 804_XCMD_SPLIT.TAR.PCF
2DD03C20: 00 80
2E00BA62: 00 80

fc /b 772_xcmd_split.TAR.pcf 804_xcmd_split.TAR.pcf
Сравнение файлов 772_xcmd_split.TAR.pcf и 804_XCMD_SPLIT.TAR.PCF
2D35B6E0: CC 00
2D43A71B: CC 00
2D4D0778: CC 00
2DD03C20: 00 80
2DD8FAE9: CC 00
2DD93038: CC 00
2DD930E3: CC 00
2DD9B49D: CC 00
2DE50932: CC 00
2E00BA62: 00 80

egor23
логично для сравнения запустить так же распаковку rar -kb. и ещё распаковку 32-битным srep, ok?

Bulat_Ziganshin

Цитата:

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

и так 32-битный, точнее 32i

Цитата:

ак же распаковку rar -kb

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

Bulat_Ziganshin
ты ПМ читаешь ?

Кто-нибудь сравнивал степень сжатия и скорость распаковки больших файлов (скорость упаковки не важна) с архиватором 7-zip?

Mercedes_Benz
Да.