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

Цитата:

ERROR: Invalid compression method or parameters in tor:1547kb:c3

это очевидно с последним exe-шником такое счас поправлю

что касается lzma: в отличие от deflate/rar он раздувает несжимаемые данные на 1-2%. в твоих exe-шниках есть небольшие сжимаемые части, которые пакуются в 3-4 раза. но их немного, пара процентов всего. с учётом того, что остальные данные не сжимаются, общее сжатие выходит 1-2%. когда же ты обрабатываешь файл lzma, то сжатие за счёт сжимаемых данных на 1-2% компенсируется раздутием несжимаемых на те же 1-2%. что делать - ждать lzma2. я могу и сам это поправить, но это в любом случае неблизкое дело, так что скорее нам придётся просто подождать Игоря

Добавлено:

Цитата:

ERROR: Invalid compression method or parameters in tor:1547kb:c3

fixed, качайте исправленную версию

egor23

Цитата:

это в соседнем топике вопрос подымался

спасибо.

Цитата:

ранимым

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

Цитата:

а в определённом направлении

у меня GUI именно куды-то

Bulat_Ziganshin
спасибо за ответ, который я хотел услышать.

Добавлено:
да, работает.

Цитата:

что касается lzma: в отличие от deflate/rar он раздувает несжимаемые данные на 1-2%.

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

Цитата:

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

Булат, а можно ли сделать, чтобы текущий каталог всё-таки менялся (ну, на сгенерированный)? ^^

Цитата:

Булат, а можно ли сделать, чтобы текущий каталог всё-таки менялся (ну, на сгенерированный)? ^^

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

Цитата:

ещё диск свой потрёт

или не свой.

Цитата:

да, есть такая недоработка

Интересно, неужели ещё никто на потерю инфы не попадал, воспользовавшись шифрованием и понадеявшись на функцию проверки архива после упаковки, раз я первый заикнулся?

Цитата:

Интересно, неужели ещё никто на потерю инфы не попадал, воспользовавшись шифрованием и понадеявшись на функцию проверки архива после упаковки, раз я первый заикнулся?

Всмысле потери?
архив что совсем не распаковывался\ не распаковывается?

egor23

Цитата:

Последняя версия. Если создать архив с шифрованием (я пробовал максимальное, про другие варианты не скажу), то при попытке открыть его архиватор зависнет (в процессах висеть будет, но окно не проявится). Если создать sfx, то при попытке запуска будет вылетать длинная ошибка.

Gideon Vi
Arc.exe распаковывает архив \ отображает содержимое архива?

Gideon Vi
не всех конечно проносило.

Цитата:

Never use such very experimental and unstable programs for your data!

Не подскажите есть ли еще какой нибудь препроцессор типа precomp???, а то последняя версия что то никак не может распаковать нормально zip архив что бы его упаковать посильнее. Пытаюсь crysis пакануть тама файлы с расширением pak распаковываются обычным 7zip или winraro'м.

Цитата:

есть ли еще какой нибудь препроцессор типа precomp

нету


Цитата:

Булат, а можно ли сделать, чтобы текущий каталог всё-таки менялся (ну, на сгенерированный)? ^^

fixed. файлы после окончания setup.exe удаляются так что лучше убери это из своих скриптов

DemonAk
Цитата:

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

-slow пробовал? В конце концов можно попробовать распаковать zip, запаковать тем, чем надо, затем взять любой консольный deflate (ну, zip) архиватор, и носить его с собой в дистрибе, запаковывая всё заново при установке. Правда, не факт, что архивы будут байт-в-байт идентичны после упаковки, т.е. не факт, что крайзис их нормально воспримет. И происходить всё это будет медленнее, чем у precomp'а (хотя он, по сути, примерно то же самое делает, просто немного на другом уровне).
Если бы мне обязательно нужно было выиграть пару сотен мегабайт, я бы так и сделал.

Bulat_Ziganshin
Цитата:

fixed. файлы после окончания setup.exe удаляются так что лучше убери это из своих скриптов

Спасибо Буду пробовать

IamFool

Цитата:

-slow пробовал? В конце концов можно попробовать распаковать zip, запаковать тем, чем надо, затем взять любой консольный deflate (ну, zip) архиватор, и носить его с собой в дистрибе, запаковывая всё заново при установке. Правда, не факт, что архивы будут байт-в-байт идентичны после упаковки, т.е. не факт, что крайзис их нормально воспримет. И происходить всё это будет медленнее, чем у precomp'а (хотя он, по сути, примерно то же самое делает, просто немного на другом уровне).
Если бы мне обязательно нужно было выиграть пару сотен мегабайт, я бы так и сделал.

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

DemonAk

Цитата:

носить его с собой в дистрибе, запаковывая всё заново при установке

проще прикрутить как метод упаковки (для распаковки\упаковки zip-архивов) zip_unpak_pack

Цитата:

не факт, что архивы будут байт-в-байт идентичны после упаковки

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

Добавлено:
DemonAk
А вообще какова цель данных манипуляций?
насколько помню, там можно попробывать перепаковать сам дистрибутив ресурсы лежат в cab-архиве, получаете cab-zip-ресурсы.

Цитата:

Цитата:
есть ли еще какой нибудь препроцессор типа precomp

нету

Есть ещё goodmerge, но у него специфика узкая вроде.

Engaged Clown
Цитата:

Есть ещё goodmerge, но у него специфика узкая вроде.

Да уж, и вправду узкая Он пакует/распаковывает ROM'ы для эмуляторов различных приставок. И он требует .NET 2.0, что абсолютно непримемлимо для программ такого рода.

2 Булат: Пофиксил ли ты поведение программы при неправильном указании пароля?

1) Необходимо чтобы arc.com возвращал специальный код ошибки при неверно указанном пароле, а не перезапрашивал его;
2) Еще необходим какой то признак того, что архив зашифрован.

Просто есть возможность продолжить разработку Warc'a.

Цитата:

1) Необходимо чтобы arc.com возвращал специальный код ошибки при неверно указанном пароле, а не перезапрашивал его;
2) Еще необходим какой то признак того, что архив зашифрован.

посмотрю

я исправил ошибку с tor и tor:c3 в последней сборке. и добавил использование tta:m1 в -m4xx

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

Цитата:

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

такой ключ есть - "-p-". т.е. команда

arc l archive -pPWD -p-

должна выругаться если каталог архива запаролен и пароль PWD не подходит, а команда

arc x archive -pPWD -p-

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

а вообще почитай описание шифрования и ключей -p/-op

ты это когда сделал?
arc l archive -pPWD -p-

SCINER

Цитата:

ты это когда сделал?

мануал написан год назад (01.01.2008).

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

это было сделано полтора года назад. мануал посмотрю

Спасибо.

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

почему этим должен заниматься архиватор, а не сам пользователь?
потому что если архивы и вправду независимые, то и распаковывать их надо по-отдельности, а если это (независимые) тома, то архиватор при распаковке сам найдет их все

еще подумалось, что при работе с томами напрямую из интернета, FreeArc мог бы подкачивать конец предыдущего / начало следующего тома при необходимости распаковать пограничный файл

sabio

Цитата:

пришла в голову вот такая идея

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

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

sabio

Цитата:

при этом тома будут получаться меньше указанного максимального размера

Не, спасибо, вот такой радости не надо.

Если задано в параметрах, что том должен иметь размер, к примеру, 100 мегабайт, то он и должен иметь именно такой размер. А не так, чтобы один том, скажем, 80, другой 75 а третий 95 (возможны и более экзотические варианты).