» FreeArc (часть 4)

[more] Я столкнулся с проблемой при распаковке FreeArc-архивов.
Всё началось с того, что перестали устанавливаться скачанные с торрентов репаки игр. Углубление в проблему показало, что не

ставятся только те репаки, в которых использован FreeArc для сжатия данных. Обычно процесс распаковки прерывается одной из

следующих ошибок:
- Заголовок "srep". Архив повреждён;
- Заголовок "IsDone.dll". Unarc.dll вернул код ошибки -7: архив повреждён;
- Заголовок "IsDone.dll". Unarc.dll вернул код ошибки -12: несхождение контрольных сумм.

Открывая файл (как правило, data.bin в репаках) стандартным клиентом FreeArc я вижу дерево файлов, но успешно могу

разархивировать только часть из них. При попытке разархивировать остальные программа просто закрывается.

Я пытался решить проблему, постепенно отсекая причины, которые не могли вызвать ошибку:
1) Первое, что бросается в глаза: наверное, действительно "архив повреждён". Но я проверял работу со многими разными репаками

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

SHA-1 хэшу.
2) Я заподозрил неполадки с оперативной памятью, проверил. Одна планка и в самом деле оказалась битой, но её удаление не

помогло.
3) Я поставил свежие библиотеки Unarc.dll и IsDone.dll в system32 и зарегестировал их в системе командой regsvr32. Не спасло.

Проверял даже до и после регистрации файлов. Кроме того, раньше в system32 этих файлов не было вообще, как они могли

возвращать какой-то код ошибки?
4) Наконец, я просто запаковывал и распаковывал обратно файлы при помощи FreeArc на своём компьютере и не смог воспроизвести

ошибку снова. Правда, файлы я использовал небольшие.
5) Ещё я подметил, что впервые столкнулся с проблемой около месяца назад, до этого всё было в порядке. Значит, система и

конфигурация железа врял ли виновны.

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

уже был: в интернете он встречается очень часто, а конкретно в этой теме уже 110 страниц.
Любопытно, что на форумах можно найти много людей, решивших эту проблему совершенно "шаманскими" способами. Дело в том, что

ошибка возникает в случайный момент, и может так случиться, что не возникнет вообще за всё время установки (но файлы

распакуются не все). Тогда, вероятно, пользователь думает: "Баг у становкой я победил, а игра сама по себе у меня не идёт".
Ещё забавный факт: репаки для релиза на торрентах как правило создаются при помощи связки Inno Setup + FreeArc, из-за чего

получается своеобразный "бич пирата" - глюк, который возникает только у любителей халявы. [/more]

сейчас переделываю FA чтобы данные паковались с precomp 0.4.3. вроде единственное изменение в нём по сранению с 0.4.2 - то что вместо опции -c- надо использовать -cn? как вообще эта версия - не стала менее надёжной чем прежняя?

Bulat_Ziganshin
Нужно будет держать рядом precomp042.exe и precomp043.exe или просто заменить первый вторым?

Skif_off
паковаться будет теперь версией 0.4.3. для распаковки архивов созданных прежде нужна будет версия 0.4.2. freearc будет включать обе версии precomp.exe; в архив записывается какая версия precomp использовалась для сжатия, так что нужная для распаковки версия будет выбираться автоматически

вот как будет выглядеть новый arc.ini:

precompj = precomp043:cn
...

[External compressor:precomp042,precomp043]
mem = 2
packcmd = {compressor} {options} -o$$arcpackedfile$$.tmp $$arcdatafile$$.tmp
unpackcmd = {compressor} -o$$arcdatafile$$.tmp -r $$arcpackedfile$$.tmp

PoseidonGuest
а ты не можешь для начала совсем поменять память? убрать разгон конечно если есть. мы сталкивались с проблемами распаковки srep и в конце концов даже появилась гипотеза что srep нагружает компьютер сильнее тестов и поэтому может сам служить тестом памяти. но это конечно хороший предлог не искать в нём ошибки

потом - разрегистрируй и сотри dll из system32. они должны идти в комплекте инсталятора, и разные их варианты несмотря на одинаковое название несовместимы друг с другом. это даже как вариант объяснения проблемы - какая-то левизна подхватывается у тебя из path

Всем привет. Я к вам обращаюсь с вопросом, касается сжатию. Я делаю репак на Crysis, использую скрипт от Механиков, а во время установки вылезает ошибка.
Вот скриншот: http://www.pictureshack.ru/view_32821_Bezymyannyi.jpg
Дайте исправленный arc.ini или другой файл, чтобы этот алгоритм работал. Заранее спасибо. Жду ответа!
И еще сам скрипт на всякий случай: http://repacks.org.ua/inno-setup/skripty/75-dino-crisis-mexaniki-ot-shopack98.html

[more] Bulat_Ziganshin, к сожалению, совсем память поменять я не могу. Нет под рукой ноутбучной планки. Говоря, что одна из них битая, я немного упростил: на самом деле, обе имеющиеся оперативки по отдельности проходят тесты, но вместе плодят ошибки. Пришёл к выводу, что глючит слот на материнке. Впрочем, я проверял распаковку трижды, для каждого случая отдельно. Так что, похоже, дело всё-таки не в оперативке, или не только в ней. Тест памяти я проводил вне ОС, с помощью memtest+, он достаточно надёжный.

Версия с несовместимыми dll тоже отпадает, так как я сделал несколько попыток до того, как добавил в систему unarc.dll и isdone.dll. А библиотеки, приложенные к инсталлятору, неподходящими быть не могут, иначе бы у других скачавших тоже ничего бы не ставилось. К тому же, я использовал и сам клиент FreeArc, а он использует библиотеки, идущие с ним в комплекте, верно?

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


Цитата:

srep нагружает компьютер

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

Офф-топик. Только сегодня попался на глаза топик на habrahabr.ru про FreeArc, Вы, Bulat_Ziganshin, упомянуты в нём как единоличный автор проекта (к слову, оказалось, что мы живём в одном городе). Но выше Вы писали

Цитата:

мы сталкивались с проблемами распаковки srep

А кто это мы? Выходит, сейчас Вы ведёте разработку уже не в одиночестве? [/more]

anton210896
вы серьёзно полагаете что механики опубликовали нерабочий комплект?

Bulat_Ziganshin
В файле по ссылке http://repacks.org.ua/inno-setup/skripty/75-dino-crisis-mexaniki-ot-shopack98.html есть архив Data.arc, при попытке распаковать получаю ошибку

Цитата:

user error (Unsupported compression methop or error in parameters: precomp)

FreeArc крайняя альфа.
В Mulitarc ошибка

Цитата:

Executed command ... returned errorlevel 1 бла-бла, проверьте конфигурацию

errorlevel 1, так понимаю - Some error when (de)compressing.
В чем может быть дело?

[more] [more]
Цитата:

если это код из unarc.dll, то сбойные сжатые данные

#define FREEARC_ERRCODE_BAD_COMPRESSED_DATA (-7) /* Data can't be decompressed */

да из unarc
странно но эта ошибка то бывает, то все ок, на моем компе ок, люди скачивают файл, у кого-то code -7, а у кого-то ошибки нет. причем сам файл в свою очередь упакован в несжатый рар-архив вместе с exe-шником инсталятора и прочей лабудой
я заметил что такая ошибка довольно часто проявляется если размер arc-архива ~1.2Gb и более, при архивах до гига такого вообще не случается. Большой размер архива делает его то ли нестабильным то ли чувствительным к закачке с инета (если перекопаковать с LZMA2 то все ок хотя сам архив получается еще больше)
сами данные ессно не могут быть сбойными, декомпрессия у меня происходит без проблем, архив не битый, у пользователей (которые скачали с инета данные) другие мои установщики с меньшими по размеру arc-архивами проблем не создают
но как быть если скажем сжимаемый файл очень большой (не думаю что резать его винраром, чтобы потом пораспихать на мелкие arc-архивы, будет хорошей идеей)
мои исследования пока сводятся к тому что с фриарком очень велика вероятность получить эту ошибку скачивая большие архивы, при этом повторное скачивание с других зеркал либо мультипарт-рар пакета в котором есть большой фриарк-архив зачастую решает эту проблему, архив каким-то образом бьется при закачке из инета (даже если он внутри винрар-архива), но происходит это почему-то лишь с большими архивами, на моей практике ошибки начинают появляет начиная примерно с 1,2гб и более
[/more] [/more]

Цитата:

Unsupported compression methop or error in parameters: precomp

такого метода в fa действительно нет, обращайтесь к создателю архива

cross125
может ты расскажешь как конкретно упаковываешь, чем сбойные архивы кроме размеров отличаются от несбойных? или мне искать ошибку при распаковке архивов с размером 1.2 гб?

и перестаньте под more прятать текст

Дополнительная инфа:
скопировал все из \include в \bin - ошибка при запуске precomp.exe:

Код: Сигнатура проблемы:
Имя события проблемы:    APPCRASH
Имя приложения:    precomp.exe
Версия приложения:    0.0.0.0
Отметка времени приложения:    4d0fc462
Имя модуля с ошибкой:    packJPG_DLL.dll
Версия модуля с ошибкой:    0.2.1.0
Отметка времени модуля с ошибкой:    4e900bc9
Код исключения:    c0000005
Смещение исключения:    00001d55

сорри, more он сам дорисовал, я не вставлял спецом, думал так задумано автоматом если много текста
по теме: упаковываю только с методом best assymetric (так лучше сжимает в моем случае, делает винрар стабильно на 5-10мб)
кроме размеров ничем не отличаются, формат и структура файлов одинаковые (там 1 файл 4гб)
как искать ошибку даже не знаю, эта проблема вылазит только при передаче через инет, бывает что человек скачал с ресурса и поймал ошибку, удалил файл, затем скачал снова и уже нет ошибки (но надежнее скачать с другого ресурса с более высокой скоростью) - и вот такая борода именно с большими файлами случается. У себя я эту ошибку никогда не ловил (у меня то файлы локально хранятся)
попробуйте создать очень большой архив (под 2гб например), и залить на депозит и яндекс, с яндекса норм у людей качается т.к. скорость быстрая а с депозита медленно и вероятность появления ошибки выше

Цитата:

сейчас переделываю FA чтобы данные паковались с precomp 0.4.3. вроде единственное изменение в нём по сранению с 0.4.2 - то что вместо опции -c- надо использовать -cn? как вообще эта версия - не стала менее надёжной чем прежняя?

Изменение синтаксиса - это лишь малая часть отличий версии 0.4.3 от 0.4.2.
Версия 043 скомпилена статически и представляет теперь один exe файл, так что меньше размер и нет проблем с возможными конфликтами из-за файлов packjpg_dll.dll и zlib1.dll (хотя для некоторых целей это не гуд).
Движок PackJPG обновлен с 2.4wip4 до 2.5a и как следствие меньше глюков при включеной обработке JPEG. Пофиксен баг с GIF файлами, когда например на vm.dll найденые GIF файлы раздувались в temp файлы размером под 4 Гб.
Разные фиксы и улучшения, типа возможности нескольким копиям Precomp работать на одном файле, сохранении корректного имени файла в заголовке (раньше всё хранилось в lower case) и др и пр.
Но самый вкусный момент это скорость.
Fallout - Textures.bsa + Fallout - Textures2.bsa (Fallout NV)
RAMDisk (ImDisk -awe)


Код: 0.4.2 -intense -c- 727 sec.
0.4.3 -intense -cn 581 sec. <- 20% быстрее

Цитата:

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

это проблема не в архиваторе, а в довнлоадере. поищите каким лучше пользоваться для надёжной скачки, у меня лично download master

для проверки можешь добавить в архивы доп. контрольную сумму опцией -rr0.01%, тогда freearc будет ругаться ещё до распаковки если эта КС нарушена

Расшифруйте пожалуйста, сколько реальной памяти понадобится для распаковки при таких параметрах:
1.rep:256mb+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128
2.rep:256mb+lzma:64mb:h64m:normal:bt4:128

В win8 fa не интегрируется в контекстное меню проводника. Исправте в след. версии.

hammerxp1
256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Highpass
спасибо!

В FreeArc 0.67 надо что-то поправить с опцией --dirs. Она не работает корректно, когда ограничено множество извлекаемых из архива файлов, и создаёт пустые директории, выходящие за пределы этого множества. Кроме того, вообще странно, что по умолчанию эта опция для извлечения как будто бы отключена (хотя добавить её в .ini файл или в настройки для FAR не сложно). В помощи по этой опции написано, что она относится к добавлению файлов, но сейчас речь идёт исключительно об извлечении, на которое она тоже влияет (может быть, по идее, не должна?).

И другой момент: Addons\FAR MultiArc plugin\custom.ini.addition приходится изменять, чтобы работало правильно во всех случаях. Исходно так:

Extract=arc x --noarcext -y -fn {-p%%P} -kb {-ap%%R} {%%S} -- %%A @%%LNM
ExtractWithoutPath=arc e --noarcext -y -fn {-p%%P} -kb {%%S} -- %%A @%%LNM

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

Extract=arc x --noarcext -fn {-p%%P} -kb {-ap%%R} {%%S} -- %%A @%%LMW
ExtractWithoutPath=arc e --noarcext -fn {-p%%P} -kb {%%S} -- %%A @%%LM

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

Цитата:

256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?
Или 256+132 это сколько требуется памяти на поток? Потому что если выставить одноядерный процессор то всё работает.
Без параметра 4x4 всё отлично, но с моим количеством обрабатываемых данных (около 40гб) не хватает скорости, а 4x4 дает ускорение при распаковке минимум в 2 раза.
Пока что перешёл на эксперименты с rep:256+tor:15, разница в размере получаемого архива не такая значительная, зато скорость распаковки почти в 2 раза выше. Кстати tor:16 при упаковке тоже не хватает памяти.

у меня две новости:

1. я начинаю подготовку к выпуску 0.70. сейчас напишу всем переводчикам, чтобы они обновили свои файлы. из присутствующих здесь у нас есть автор белорусского перевода, в котором надо обновить 21 строку. думаю за 3-4 недели переводчики управятся

2. сегодня со мной связался Артём Дробанов, автор RecoveryStar (инсталятор) и предложил план по добавлению кодов Рида-Соломона в FreeArc. Я ему свои пожелания как автор программы высказал, теперь можете высказаться вы. От каких ситуаций нужно защищаться, какой объём данных добавлять, какая скорость защиты/проверки/восстановления будет приемлема

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

Не очень понимаю надобность двух баров. Функция бара -- показывать какой процент работы выполнен, с его помощью можно составить прогноз, когда работа будет закончена. Если я правильно понял, верхний бар показывает, какой процент файла обработан. Но для чего это? После обработки одного файла архиватор сразу же приступает к обработке другого. Архиватор пакует файлы не друг за другом, а выборочно, по кучкам. Невозможно прервать процесс, и получить рабочий архив с определенным файлами.

Верхний бар имеет смысл при копировании файлов, при этом процессе ты можешь передумать о своих планах и остановить процесс, при этом сохраняя выволненную работу.

Другие предложения:
1) Мне очень не нравятся пустые места между параметрами и значениями. (Time-много-пустого-места-0:12).
2) Больная часть исходных данных, по моему мнению не нужна. Количество файлов смело можно выкидывать, с этой информацией ничего не поделаешь (не остановится же пользователь посередине архива, достигнув магического числа). Текущий размер во время обработки выкидываем по той же причине. Также не вижу, зачем нужен размер информации (исходный и обработанный), роль заменяется процентом.
3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!
4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час. Вместо 'of' можно использовать слэш. Идея из uTorrent.
5) Заголовок: я бы поменял вертикальныю черту на слэш. Но это на усмотрение, у меня какая-то нелюбовь к этому знаку. Еще можно поставить разделитель между процентом и временем.



Вместо жирности можно использовать различие размеров шрифта, сейчас это модно, и смотрится неплохо.


Добавлено:
По поводу набора команд в меню Explorer. Некоторы предложения для строк.

1) Выкиньте 'the selected files' -- файловое меню не показывается при отсутствии выделенных файлов
2) 'using Freearc' -> '(Freearc)', или 'with Freearc', 'via Freearc' (сэкономит целый симбол в меню); еще лучше совсем Freearc выкинуть, как в меню 7-Zip. Мы же все равно рассчитываем, что Freearc в скором будущем станет единственный архиватором на машинах пользователей
3) '... via dialog', 'Extract, Test with Freearc' -> Compress, Open, Extract, Test archive (tnx 7-Zip).
4) 'Extract to a folder', 'Extract here'.


Добавлено:
В голову пришла еще одна замечательнаяы идея. Вчера смотрел видео на ted.com, понравилось как у них время отображается по краям на прогресс-баре. Идею с легкостью можно перенести и сюда.

Прогресс = Обработано данных/ Всего данных
Всего времени = Прошло времени * (Всего данных/Обработано данных)
Прошло времени / Всего времени = Обработано данных / Всего данных

Превьюшка с метро-дизайном


Добавлено:
И в дробных числах лучше использовать точку, я не запятую.

Цитата:

От каких ситуаций нужно защищаться, какой объём данных добавлять, какая скорость защиты/проверки/восстановления будет приемлема

Если отталкиваться от реальности - например торренты, фактически с проверкой/коррекцией, то 0%
FDD сейчас не наблюдается.
На флешках/hdd если выпадает - то сектор (512 байт) - тоже мало смысла.
Пожалуй Единственные каналы передачи, где встречаются ошибки (из реально встречающихся на данный момент) - GPRS и протокол http.
остальное - сильная экзотика.

Не припомню чтобы за последние 10 лет что-то успешно восстановилось, чтобы от рекавери инфы была польза.

ndch

Цитата:

Не припомню чтобы за последние 10 лет что-то успешно восстановилось, чтобы от рекавери инфы была польза

Это Вы зря так...
Свежий пример. Недавно слил инфу с компа на внешний USB-HDD, этак 140Гб, освободил место
Потом кинулся читать - все архивы битые. (Как потом выяснилось - взглючил USB-шный контроллер, и кроме ошибок еще подсаживал этот HDD по питанию, так что в конце-концов пришлось материнку менять).
А вытащил всю инфу именно через рекавери. Т.к. уже давно - RAR с -rr10p (именно из-за рекавери и RAR).

Bulat_Ziganshin

Цитата:

предложил план по добавлению кодов Рида-Соломона в FreeArc

Цитата:

какой объём данных добавлять

ИМХО, как в RAR - опцию, и на усмотрение пользователя...
А по-поводу ситуаций, скорости защиты - надо пробовать...

UbiSergei
Первый бар (в моем предложении) - "процент" выполненой работы (в целом, а не по файлам!)
Второй бар - размер "архива", т.е. показатель "эффективности" работы!

Bulat_Ziganshin
Я сейчас может не в тему, со своими мелкими просьбами, но очень понравилась плюшка из Bandizip-a - Extract Automatically.
Реально добавить в freearc?

Shuld
Значит второй бар просто показывает коэфициент сжатия, понятно. Как обидно это было бы не говорить, но надобности в нем тоже не вижу: на протяжении процесса жизни ратио колеблется слабо. Бары для вещей у которых есть начало и конец, ратио же почти постоянен.

Это же идея из винрара? Похоже, что авторы изначально не продумали концепцию.

Цитата:

Реально добавить в freearc?

да, такое есть в планах

UbiSergei
Вы постоянно путаете.
В WinRAR как раз по-файлово.