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

ruduk

Цитата:

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

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

sabio

Цитата:

похожая штука есть для 7-zip - см. в шапке соседней темы про "многотомные sfx"

нашел близкое по смыслу - Модифицированный SFX модуль 7-Zip'а для установок, но как его скачать?

V0lt
напиши батник c командами распаковки, а затем скомпилируй его в exe например вот этим

crotoff
Спасибо, но есть мысля сделать что-то более универсальное с помощью Inno setup.

V0lt

Цитата:

но как его скачать?

так ведь в шапке темы по 7-zip как раз и есть ссылка для загрузки:
http://gora.7zsfx.info/addons/Loader.7z.000_s2_090925_11-11.7z

sabio

Цитата:

так ведь в шапке темы по 7-zip как раз и есть ссылка для загрузки

Ой,

Да, а меня всё ещё волнует вопрос: насколько трудно реализовать Extreme Long Rep - т.е. rep вообще без словаря? Потому что с появлением и распространение быстрых SSD с микроскопической латентностью оно становится по настоящему актуально. В принципе, такая штука планируется? Хотя бы к версии 1.0, или даже 2.0, а то и 2.5 . Потому что десятки Гб образов консольных игр на нескольких дисках всё ещё валяются мёртвым грузом - при том, что совпадения там длинные, вполне вероятно более 10-ки кб (не говоря уж о пределе нынешнего rep'а в 4 кб) - и такая штука их бы в разы сжала. А так единственный вариант - бить файлы образов (предварительно пройдясь по ним обычным rep'ом с совпадением порядка 128) на куски по 700 Мб и в ручную искать пары кусков, которые хорошо сожмутся ещё одним rep'ом на 1400 Мб - а это занятие очень долгое и утомительное, да ещё требующее разбиение на большое количество временных файлов (впрочем, тут multivolime может сильно помочь)...

Впрочем, вопрос в том, насколько быстро такая штука будет упаковывать и распаковывать... Ведь там хеш требуется более стойкий - а это наверное выйдет медленней. Но наверное размер мин. совпадения 4-64 кб может заметно ускорить хотя бы сжатие... Ну а расжатие тут уж по любому будет скорее от латентности зависеть (т.е. на HDD тормоза наверняка обеспечены (со словом 128-512 байт - уж точно) - но новые SSD этой проблемой не должны страдать). С другой стороны, очень большая мин. длина, вроде 16-64 Кб может с этим здорово помочь.

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

далее. в lrzip оказывается не только описана эта идея, но и есть готовая программа, которая однако только оценивает степень сжатия. мне удалось откомпилить её только под linux: http://freearc.org/download/testing/find_stream_match

кстати, её скорость вполне приличная - 20 мб/сек. используется проверка по crc+md4

Ghost2004
http://freearc.org/download/testing/srep.exe:

>t srep.exe <D:\testing\!!!\5g
512 mb used for hash (filesize/12, rounded up to power of 2)
5586729972 -> 4575184372: 81.89%
Elapsed time = 432.297 seconds

таким образом, сейчас можно обрабатывать файлы размером до 24 гб

обновил http://freearc.org/download/testing/srep.exe и добавил 64-битный http://freearc.org/download/testing/srep64.exe

теперь они выводят сжатые данные, но распаковки пока нет

now decompression works too. i've constructed the following batch for its testing:

timer srep.exe %1 1
timer srep.exe -d 1 2
arc a a -mcrc %1 2
arc v a

archive listing given by las command should show the same CRC values for both files

Bulat_Ziganshin

Цитата:

srep.exe

взял файлик iso 7678.5МБ, сделал копию, заtarил, получил файлик 1.tar 15357МБ
srep.exe 1.tar 2222
1792 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -1076818944 -> 3: 0.00%

файлик 2222 имеет размер 7633.1МБ (данные в iso возможно немного сжимаемые)

Цитата:

512 mb used for hash (filesize/12, rounded up to power of 2)

требования к памяти: filesize/12 + 2*256МБ

Добавлено:
srep.exe использовался от "21:45 22-11-2009"
неплохо дату:время вставлять, чтобы путаницы не было с версиями ПО.

Добавлено:
Bulat_Ziganshin

Цитата:

constructed the following batch for its testing:

timer.exe srep.exe 1.tar 2222
timer.exe srep.exe -d 2222 3333
+ весёлые картинки Process Explorer, (скорость диска ~60МБ\с)

timer.exe srep.exe 1.tar 2222

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1792 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -1076818944 -> 3: 0.00%

Kernel Time = 73.468 = 00:01:13.468 = 5%
User Time = 1203.078 = 00:20:03.078 = 83%
Process Time = 1276.546 = 00:21:16.546 = 88%
Global Time = 1443.828 = 00:24:03.828 = 100%



timer.exe srep.exe -d 2222 3333

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
Compression ratio: -1076818944 -> 3: 0.00%

Kernel Time = 172.359 = 00:02:52.359 = 21%
User Time = 33.062 = 00:00:33.062 = 4%
Process Time = 205.421 = 00:03:25.421 = 25%
Global Time = 817.828 = 00:13:37.828 = 100%

Цитата:

требования к памяти: filesize/12 + 2*256МБ

filesize/12 + 2*XXXМБ
по какому принципу XXX выбирается?

filesize/12, округлённое вверх до степени 2. в последней версии 7/8 от этого объёма. далее ещё чуть уменьшу, будет 6-8% от размера файла

Bulat_Ziganshin

Цитата:

filesize/12, округлённое вверх до степени 2

не совсем понял про округление
было выделено filesize/12 + 2*256МБ
filesize/12 - "ровно" 1\12, т.е 15357\12 = 1280МБ

подтянулись реальные данные Devil.May.Cry.4
http://forum.ru-board.com/topic.cgi?forum=5&topic=29437&start=1340#9
2.205 files of 7.702.106.956 bytes
заtarены в DEVILMAYCRY4.TAR 7347МБ

timer.exe srep.exe DEVILMAYCRY4.TAR 2222
timer.exe srep.exe -d 2222 3333
+ весёлые картинки Process Explorer, (скорость диска ~60МБ\с)

timer.exe srep.exe DEVILMAYCRY4.TAR 2222

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
896 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 87.875 = 00:01:27.875 = 12%
User Time = 501.828 = 00:08:21.828 = 73%
Process Time = 589.703 = 00:09:49.703 = 86%
Global Time = 684.703 = 00:11:24.703 = 100%

файлик 2222 получился 2861.4МБ
задача была приблизиться к 2759МБ (столько весят эти данные в RIP-е)
дожимаем: WinRAR скоростной - 2731.9МБ, что близко к цифре 2725МБ, которая была ранее
http://forum.ru-board.com/topic.cgi?forum=5&topic=29437&start=1340#21



timer.exe srep.exe -d 2222 3333

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 75.640 = 00:01:15.640 = 25%
User Time = 16.281 = 00:00:16.281 = 5%
Process Time = 91.921 = 00:01:31.921 = 30%
Global Time = 300.531 = 00:05:00.531 = 100%

Цитата:

не совсем понял про округление
было выделено filesize/12 + 2*256МБ

1280мб округлённое вверх до степени 2 = 2048 мб

ты распакованный файл с орнигиналом сравнивал? по crc/md5...

в srep64 есть ошибка - он не распаковывает файлы больше 2 гиг

Bulat_Ziganshin

Цитата:

ты распакованный файл с орнигиналом сравнивал? по crc/md5...

конечно, по md5 всё совпало

Цитата:

1280мб округлённое вверх до степени 2 = 2048 мб

srep 32-bit, Win32 (VM 2ГБ)
было выделено 1280 +2*256МБ = 1792МБ (это что было)
версия srep от "01:14 23-11-2009"
или округление вверх до степени 2 в новой версии будет, 1280 до 2048МБ как-то не очень катит, или это округление в srep 64-bit?


Цитата:

файлик 2222 получился 2861.4МБ
задача была приблизиться к 2759МБ (столько весят эти данные в RIP-е)
дожимаем: WinRAR скоростной - 2731.9МБ, что близко к цифре 2725МБ, которая была ранее

дожимаем 2222 rep с разными настройками:
rep:128m - 2739.6МБ
rep:128m:64 - 2730.3МБ
rep:128m:32 - 2729МБ
rep:128m:16 - 2728.1МБ

непонял?!
srep.exe -l256 DEVILMAYCRY4.TAR 2222_256
Can't allocate memory: 1792 mb required (filesize/12, rounded up to power of 2)

srep.exe -l128 DEVILMAYCRY4.TAR 2222_128
Can't allocate memory: 3584 mb required (filesize/12, rounded up to power of 2)

srep.exe -l64 DEVILMAYCRY4.TAR 2222_64
Can't allocate memory: 7168 mb required (filesize/12, rounded up to power of 2)

1280мб округлённое вверх до степени 2 = 2048 мб. 7/8 от этого - 1792 мб

Добавлено:

Цитата:

Can't allocate memory: 1792 mb required

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

Добавлено:
да, объм выделяемой памяти прямо пропорционален l. написанное в скорбках верно только для -l512

Здорово, классная вышла программа. У меня на Атлоне 64 X2 с 2.2 ГГц (вот только память там DDR314 двухканальная) скорость сжатия вышла в районе 6 Мб/с для плохо сжимаемых данных, и 10-15 Мб/с - для PS2-игры, которую с одной DVD9 запихнули на 2 DVD5 - т.е. с массой повторов. Жёсткие диски у меня обычно выдают порядка 40 Мб/с.

Короче, результаты (для 0.2 версии 32-битной) вышли такие:
3 372 449 792 rg2dvd5-1.iso -> 2 806 453 152 rg2dvd5-1.l512.srep
Полное время сжатия - 513 сек, распаковки - 215 сек.
4 533 911 552 rg2dvd5-2.iso -> 3 823 207 128 rg2dvd5-2.l512.srep
Полное время сжатия - 761 сек, распаковки - 287 сек.

Оба образа запихнутые в один тар:
7 906 363 392 bc-rg2dvd5-1+2.tar -> 4 238 863 720 bc-rg2dvd5-1+2.l512.srep
Полное время сжатия - 727 сек(правда, тут скорее всего сыграл ещё тот факт, что с другого физического диска сжималось), распаковки - 515 сек.

Что интересно, объём прочитанного (в диспетчере задач) оказывается близок к 4xразмер исходного файла. Правда, тут наверное много чтений из кэша.

Во всех случаях не только crc распакованные совпали, но и побайтовое сравнение в Totalcmd выдало идентичные файлы.

К сожалению, распаковка в этой версии (0.2) не работает, если при сжатии выставить мин. длину отличную от стандартных 512 (пробовал 2048 и 4096 - выдаёт ошибку - а они ведь при сжатии памяти меньше требуют - в 4 и 8 раз соответственно - а то на моих win32 даже l256 вряд ли пройдёт для 7 Гб-ного файла).

Да, и ещё: обнаружил одну ошибку в freearc'е - даже версия 18-ого ноября у меня при -mex5 выдаёт "ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb".

Что интересно - в том наборе было много (порядка 50-ти) файлов .tga - так вот, на их сжатии mm+grzip и даже просто grzip сильно снижает скорость. Даже в m8b lzma быстрее. Насчёт упаковки точно сейчас не вспомню, а вот при распаковке отключение grzip'а даёт 15 Мб/c (m8b или mex4 с отключённым grzip'ом). Выключение mm даёт 9.5 Мб/с для ex4, а вот режим по умолчанию, где каждому tga-файлу выделяется по солид-блоку - лишь 4 Мб/с. Хотя mx по умолчанию ещё медленней - наверное текстовый компрессор не свои файлы решил сжимать - скорость распаковки до 2.6 Мб/с упала. При этом размеры архива мало отличаются - плюс-минус 400 кб к общему размеру 21 Мб. И лучше всех вариантов сжимает m8b. Да, а размер исходных файлов - сейвы одной игрушки - всего около 56 Мб.

Bulat_Ziganshin

Цитата:

srep.exe -l256 DEVILMAYCRY4.TAR 2222_256
Can't allocate memory: 1792 mb required (filesize/12, rounded up to power of 2)

с этим разобрался, было недостаточно памяти

timer.exe srep.exe -l256 DEVILMAYCRY4.TAR 2222_256
2222_256 = 2928.6МБ
[more=Timer 3.01..]
Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1792 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 88.234 = 00:01:28.234 = 10%
User Time = 587.640 = 00:09:47.640 = 70%
Process Time = 675.875 = 00:11:15.875 = 81%
Global Time = 828.313 = 00:13:48.313 = 100%
[/more]

timer.exe srep.exe -l1024 DEVILMAYCRY4.TAR 2222_1024
2222_1024 = 2830.5МБ
[more=Timer 3.01..]
Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
448 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 25.500 = 00:00:25.500 = 4%
User Time = 421.765 = 00:07:01.765 = 81%
Process Time = 447.265 = 00:07:27.265 = 86%
Global Time = 520.047 = 00:08:40.047 = 100%
[/more]

timer.exe srep.exe -l2048 DEVILMAYCRY4.TAR 2222_2048
2222_2048 = 2822.1МБ
[more=Timer 3.01..]
Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
224 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 21.625 = 00:00:21.625 = 4%
User Time = 397.250 = 00:06:37.250 = 81%
Process Time = 418.875 = 00:06:58.875 = 86%
Global Time = 486.093 = 00:08:06.093 = 100%
[/more]

timer.exe srep.exe -l4096 DEVILMAYCRY4.TAR 2222_4096
2222_4096 = 2832.3МБ
[more=Timer 3.01..]
Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
112 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 21.093 = 00:00:21.093 = 4%
User Time = 393.250 = 00:06:33.250 = 81%
Process Time = 414.343 = 00:06:54.343 = 86%
Global Time = 481.656 = 00:08:01.656 = 100%
[/more]

timer.exe srep.exe -l8192 DEVILMAYCRY4.TAR 2222_8192
2222_8192 = 2857.8МБ
[more=Timer 3.01..]
Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
56 mb used for hash (filesize/12, rounded up to power of 2)
Compression ratio: -886002176 -> 1: 0.00%

Kernel Time = 20.968 = 00:00:20.968 = 4%
User Time = 390.578 = 00:06:30.578 = 81%
Process Time = 411.546 = 00:06:51.546 = 86%
Global Time = 478.125 = 00:07:58.125 = 100%
[/more]

srep 0.6:

* fixed 64-bit version, now it properly handles files >2gb
* fixed decompresion with non-default -l
* -s prints stats after each block



Добавлено:

Цитата:

а то на моих win32 даже l256 вряд ли пройдёт для 7 Гб-ного файла

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


Цитата:

даже версия 18-ого ноября у меня при -mex5 выдаёт "ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb".

я это исправил в тот же день, просто перекачай freearc

Ghost2004

Цитата:

а то на моих win32 даже l256 вряд ли пройдёт для 7 Гб-ного файла).

пойдёт сделайте например папку srep.exe.local
а в ней поместите dll-ки, с изменёнными базовыми адресами (расчитите адресное пространство процесса srep.exe)
http://forum.ru-board.com/topic.cgi?forum=5&topic=29437&start=1660#9

Цитата:

хотя из-за фрагментации памяти могут быть проблемы.

Угу, у меня без антивируса и прочих программ бывал макс. свободный блок 1700 Мб (сейчас-то вообще 1450 Мб - хотя это может и можно немного увеличить) но до 1792 Мб по-моему ни разу не дотягивал. Так что придётся ограничиться 12 Гб для l512 - а для 24 уже использовать l1024... В принципе не критично - 2048 может оказаться оптимальным, судя по тесту выше над Devil May Cry . А с такой длиной предел даже для нынешней версии и 32 бит, при максимальном непрерывным блоке меньше 1792, но больше 896 МБ - целых 32 Гб.


Цитата:

я это исправил в тот же день, просто перекачай freearc

Что-то не работает, откуда качать? В шапке этой темы все версии с такими датой и временем: 18.11.09 12:52 - как раз как у меня, которая всё равно ту ошибку выдаёт.

Добавлено:
Так, у меня srep 0.6 версии (32 bit) неминуемо вылетает при запуске. Разве что 8 Мб записать успевает - да толку... А фокус с перебазированием dll'ок надо будет попробовать...

Bulat_Ziganshin

Цитата:

srep 0.6:

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

Bulat_Ziganshin

Цитата:

программка не работает

srep.exe - Ошибка приложения
Инструкция по адресу "0x77c32a16" обратилась к памяти по адресу "0xdc847af4". Память не может быть "read".

Добавлено:
Ghost2004

Цитата:

В принципе не критично - 2048 может оказаться оптимальным, судя по тесту выше над Devil May Cry . А с такой длиной предел даже для нынешней версии и 32 бит, при максимальном непрерывным блоке меньше 1792, но больше 896 МБ - целых 32 Гб.

при 1792МБ, и 2048 длине, данных будет 96ГБ

Добавлено:

Цитата:

В принципе не критично - 2048 может оказаться оптимальным, судя по тесту выше над Devil May Cry .

Devil May Cry - это конкретный набор данных, в котором дожимать практически ничего не нужно, что там на других наборах будет, где не так много явных повтором, это надо смотреть...

Добавлено:
Bulat_Ziganshin
кстати
данные обработанные srep.exe 64bit, потом разожмутся с помощью srep.exe 32bit?

srep 0.7:

* reduced memory usage down to 6-8% of filesize. For example, 24gb file needs 256+256+960 mb chunks
* now hash keeps address of the last chunk with the same contents
* hashing improved a little
* fixed WinXP crashing bug

note: yes, 32-bit and 64-bit versions are 100% compatible with each other

Bulat_Ziganshin

Цитата:

reduced memory usage down to 6-8% of filesize.

а как сейчас объём памяти расчитывется?


timer.exe srep.exe DEVILMAYCRY4.TAR 2222

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
542 mb used for hash
Compression ratio: 7703932416 -> 2998132028: 38.92%. Cpu 15.998 mb/sec, real 13.504 mb/sec
Kernel Time = 21.375 = 00:00:21.375 = 3%
User Time = 481.562 = 00:08:01.562 = 84%
Process Time = 502.937 = 00:08:22.937 = 88%
Global Time = 570.719 = 00:09:30.719 = 100%

2222 = 2859.2МБ
дожимаем: rep:128m:64 - 2222_rep128_64.arc = 2729.2МБ

timer.exe srep.exe -d 2222 3333

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
Compression ratio: 7703932416 -> 2998132028: 38.92%. Cpu 475.460 mb/sec, real 26.814 mb/sec
Kernel Time = 73.671 = 00:01:13.671 = 25%
User Time = 16.218 = 00:00:16.218 = 5%
Process Time = 89.890 = 00:01:29.890 = 31%
Global Time = 288.375 = 00:04:48.375 = 100%

Цитата:

а как сейчас объём памяти расчитывется?

filesize*20/L + округлённое_вверх(filesize*8/L * 4/3)

а раньше было
округлённое_вверх(filesize*(20+8)/L * 4/3)

а ещё до этого
округлённое_вверх(filesize*(20+12)/L * 4/3)

Привет!
Заменил библиотеку unarc.dll с версии 3,3 на 3,4, скачивал сегодня.
Возникла большая проблема - где-то начиная с 27% скорость распаковки просто нереально упала, стала в районе 0,5Мб/сек, а то и меньше. С версией 3,3 такого не было, а была стабильно высокая скорость распаковки.
О! Вот это да... Оказывается происходило следующее - в бесконечном цикле распаковывались одни и те же файлы в одном из подкаталогов. Затем они по очереди занулялись и распаковывались снова (это были wav-файлы), т.е. типа повторной распаковки. В итоге около получаса или больше распаковка топталась на одном месте и затем, наконец, молча завалила себя и инносетап в придачу...
Архив был получен джойном из 6 сжатых разными методами. Максимальная требуемая память для распаковки составляет 384Мб для нескольких из них. Макс. блок ОЗУ у меня согласно фа - 811 метров.
К слову сказать 3,3 тоже молча отваливается на этом архиве, только значительно быстрее и где-то на 50%.


Добавлено:
Попробовал для джойна использовать последний доступный фа 6,00 от 18 новэмберя сг - эхвект ровно такой жо.
Опять джойны не пашут!

Добавлено:
Также у меня сложилось впечатление, что версия 3.4 по сравнению с 3.3 гораздо медленнее распаковывает архивы сжатые методом tta.

Добавлено:
вердикт:
пересобрал архив объединением в другой последовательности, сначала пошло все остальное, затем то что жалось тта. 3.4 все так же начала тупить, опустив скорость где-то с 90% (визуально по п/б выглядело 1+-0.5 Мб/сек ). Не дождался я окончания этого издевательства (~600 файлов ждать оставалось), т.к. перед обломом все именно так и выглядело и думаю что он бы снова настал. Откатился на версию 3.3 и это дало эффект: скорость на тта-шках, конечно, не ахти, но заметна визуально - в несколько раз выше чем в версии 3.4 и вылета не стало, т.е. все нормально распаковалось не учитывая все же низкую скорость распаковки тта, которая составляла не более 10-15Мб/сек (в пике), а в среднем была в районе 5Мб/сек.

srep 0.8:

* better compression due to improved hashing and compressed format
* faster compression on files <1gb
* MD5 integrity checking on decompressed data
* first 8 bytes of compressed file contains SREP signature, helping programs like unix magic
* exit code == 0 on success

http://freearc.org/download/testing/srep.exe
http://freearc.org/download/testing/srep64.exe
http://svn.freearc.org/freearc/trunk/Compression/REP/srep.cpp

Добавлено:
можно сказать, что разработка SREP закончена. что теперь я хотел бы увидеть:
1. сравнение сжатия srep+rep+lzma vs srep+lzma vs rep+lzma
2. скорость распаковки (с диска на диск) для действительно больших файлов (скажем, 18 гб при 1-2 гб ОЗУ)

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

Bulat_Ziganshin
Не подскажешь как sprep и srep64 добавить в arc.ini, т.е как правильно прописать?.