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

Обновил обзор
Limits of Virtual Memory in Windows - Ограничения виртуальной памяти в Windows

samthon, размер словаря уменьшить не пробовали ?

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

samthon
Дайте лог с "косячным" архивом:

Цитата:

дай лог работы команды "arc t -di+$ archive"

Добавлено:

Цитата:

но после тестирования простого архива вылетает таже ошибка на 99%

кстати чего ошибку не написали?

Цитата:

"arc a -mx -ld512mb -md640mb"

весёлая команда. -ld устанавливает лимит на память используемую при распаковке (в т.ч. ограничивает словари всех lz методов до этихз 512 мб), а -md явно устанавливает словарь lzma в 640 мб. к счастью, -ld всё же побеждает, а установка словаря в 640 мб вообще игнорируется как неподдерживаемая (лучше бы он конечно ругался)

что касается вашей проблемы - то как обычно нехватка памяти. sfx/unarc не умеет записывать промежуточные джанные в tempfile, поэтому настройка -ld здесь на самом деле привирает - памяти для распаковки потребуется больше. особенно если архиве есть текстовые файлы


Цитата:

дай лог работы команды "arc t -di+$ archive"

именно


Цитата:

multi-volume

если делать по-простому, то вещь элементарная, но народ здесь сказал, что нужно делать по-сложному. а это уже не так просто



Цитата:

Нельзя ли в memo.exe добавить опции (параметры):
1. Опционально - Пауза, чтобы после вывода процесс не завершал работу, ожидая нажатия клавиши.
2. Опционально - Сортировка по адресу блока.

посмотрю

Bulat_Ziganshin

Цитата:

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

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

Кстати, Булат, ты бы хоть написал, что планируется (или не планируется) в ближайших релизах. А то планов было громадьё, но времени, походу, на FA у тебя сейчас очень мало.

p.s. с наступающими тебя !

Bulat_Ziganshin, спасибо что прояснили ситуацию с использованием памяти ArcSfx - а то я никак не мог понять - почему при распаковке селфэкстрактора в диспетчере задач показывает использование памяти на уровне 620-640 MB, хотя при упаковке был использован ключ -ld512.

Bulat_Ziganshin
Benchmark

Цитата:

если делать по-простому, то вещь элементарная, но народ здесь сказал, что нужно делать по-сложному. а это уже не так просто

Цитата:

как в WinRAR

ну так по-сложному пусть и будет в какой-то отдалённой альфе, а сейчас по-простому - бо нада! ну как в 7зип

ориентироваться на платные проги не надо, а то в каких-нибудь отдалённых планах freearc станет платным

может рар и лучше 7зип, но я пользую последний, потому что платность большой недостаток ИМХО

Цитата:

Дайте лог с "косячным" архивом:

Код: FreeArc 0.50 alpha (June 23 2008) testing archive: h:\GameData.arc
Decoding directory: 0.00 secs
Directory decoded: 0.00 secs
Directory built: 0.00 secs
Testing 6 files, 8.252.483.094 bytes. Processed 55.1%
ERROR: Error when reading or writing data in delta

samthon

Цитата:

Если я прав, просьба подтвердить мои слова, т.к. времени на тестирования пережатия на систему с NTFS пока нет

ну так закиньте FreeArc на NTFS раздел.

Цитата:

ну так закиньте FreeArc на NTFS раздел.

Обязательно проверю, но уже не сегодня.

Цитата:

Почему он ругался именно на 99% я так и не понял

наверно потому что там была другая ошибка

Цитата:

наверно потому что там была другая ошибка

Вот наверно как раз из-за того что временный файл создался в папке с программой, которая в свою очередь находится на диске с системой FAT32, хотя лучше бы он создавался в том месте, где указано создание архива. Размер 7.68Гб, ошибка лезит на 55.1%, что примерно и равняется максимальному размеру файла на FAT32.

Цитата:

ошибка лезит на 55.1%, что примерно и равняется максимальному размеру файла на FAT32.

я говоря про ошибку на 99%.
Вы помните что за ошибка была?

Цитата:

я говоря про ошибку на 99%.
Вы помните что за ошибка была?

Помню, я даже её выложил. Смотрите пост выше, где лог выставлен.

Цитата:

Оказалось, что он у себя в папке bin создает файл $$arcpackedfile$$.tmp. Если я правильно понял, то это что-то типо временного не сжатого архива.

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


мне прислали такую просьбу:

А нельзя ли сделать SFX-stub для Win32 GUI, который бы:
а) при запуске сразу же (без вопросов) распаковывал содержимое в %temp%\%archive_name%\ (предполагается, что название файла - %archive_name%.exe)
б) после распаковки запускал файл setup.exe и сразу закрывался.
Это нужно для создания дистрибутивов на его основе =) Возможно ли такое сделать?

думаю реалищовать это, так как работы немного, а польза огромадная. потом потихоньку дополню это до большей конфигурируемости а-ля rar/7z. только две поправки:

1) надо создавать подкаталог в %temp% с уникальным именем
2) после запуска setup надо дожидаться его завершения и удалять либо целиком созданный временный каталог либо только те файлы, которые мы в него распаковали

ваши идеи?

Добавлено:

Цитата:

Кстати, Булат, ты бы хоть написал, что планируется (или не планируется) в ближайших релизах. А то планов было громадьё, но времени, походу, на FA у тебя сейчас очень мало.

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

что делать? я уже запустил щупальца во все возможные стороны, видимо надо из всего этого выбирать наиболее выгодные (по соотношению польза/затраты) направления. видимо, в первую очередь надо закончить проект "fa 0.45". далее есть огромадное кол-во вариантов. из фич я считаю наиболее важными - нормальный gui, многопоточность, многотомность, использование для backup. но помимо этих крупных и важных направлений есть множдество других вещей, иногда достаточно простых в реализации, но весьма полезных. тот же инсталлер

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

Bulat_Ziganshin

Цитата:

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

Вот я чего-то не понимаю пользу от этой вещи

Хотя наверное есть такие чудоюзеры, которые непонимают что такое папка и что такое диск
прикол какой-то

вот я бы хотел чтобы кто то сказал - да мне инсталер нужен!
и потом пусть объяснит - зачем

euheny
Я так понимаю, имеется ввиду возможность создания инсталлеров на основе FreeArc'овских SFX архивов. Путём добавления фичи автораспаковки и запуска одной из распакованных программ.

Парадигма этого реализована, имхо, в WinRAR'е, однако, как мне кажется, можно обойтись и малым: было бы здорово иметь просто возможность задать путь распаковки по умолчанию и имя файла, который нужно запустить, при создании самого SFX архива. Пусть бы это дописывалось между SFX stub'ом и самим архивом (как это делалось в реализации инсталлеров на основе 7-Zip) просто в строковом формате? И просто в реализации (как мне кажется), и просто в обращении (в случае чего, можно обойтись copy /b и тремя файлами).

Инфа от Марка Руссиновича

Pushing the Limits of Windows: Physical Memory
http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx

Преодолевая ограничения Windows: физическая память
http://blogs.technet.com/mark_russinovich/archive/2008/07/21/3151288.aspx

Pushing the Limits of Windows: Virtual Memory
http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx

Преодолевая ограничения Windows: виртуальная память
http://www.thevista.ru/page.php?id=10539

обновил http://www.haskell.org/bz/arc1.arc
изменения:

Код: Tornado 0.5:
better compression in -m1; faster -m3xt; modified -m1xx..-m4xx definitions; :t
tor:7:c1 .. tor:11:c3; support for :l not power of 2
checks at decoding in order to prevent segfaults
GRZip multithreading!
Prints CPU time and Real time for operation

Bulat_Ziganshin
первая новая версия - это старая версия? Хотя, противоречивые результаты, видно потому что на разных дисках. Compression time больше, а Real time и speed куда-то уплыли.

Добавлено:
а не, не угадал

Цитата:

Хотя, противоречивые результаты, видно потому что на разных дисках. Compression time больше, а Real time и speed куда-то уплыли.

объясняю: при многопоточности время работы cpu часто увеличивается, поскольку треды конкурируют за общие ресурсы - кеш, память, т.е. на каждый тред ресурсов достаётся меньше. но общее время работы (real time) при этом всё равно уменьшается - если конечно не запускать тредов больше, чем у нас в наличии процессоров

так что смотри просто на speed

Цитата:

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

Тоже хорошо, только по-моему можно и не удалять содержимое - setup может и сам это сделать В любом случае, что бы ни было сделано, уже "покатит".

Цитата:

Тоже хорошо, только по-моему можно и не удалять содержимое - setup может и сам это сделать

в том-то и дело, что setup не может удалить сам себя

Добавлено:
может, наглядней будет выводить время в таком формате:

Compression time: cpu 25.57 secs, real 21.63 secs. Speed 4.623 kB/s
Testing time: cpu 2.68 secs, real 3.09 secs. Speed 32.321 kB/s

?

Добавлено:

Цитата:

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

я тоже это чувствую, только с другой "стороны баррикад". фактически, для полной реализации многопоточности в fa нужно:
сделать многопоточными все 11 алгоритмов. осталось всего 10
сделать так, чтобы отдельные солид-блоки могли сжиматься параллельно


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

Bulat_Ziganshin

Цитата:

из фич я считаю наиболее важными - нормальный gui, многопоточность, многотомность, использование для backup

Отлично. Пускай это и будут приоритеты для 0.60.


Цитата:

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

Тоже спору нет. Но ведь эти дополнительные вещи так или иначе будут постепенно прикручиваться по ходу разработки.

На мой взгляд важно в первую очередь реализовать функционал, какой на данный момент еще отсутствует во FreeArc, но есть в WinRAR и 7zip. Плюс чтобы оно работало стабильно. Вот тогда уже можно будет думать о полной и окончательной их замене на FA.

кстати, кол-во загрузок растёт несмотря на отсутствие прогресса:
Dec 2008 4,027 15.8 GB

Bulat_Ziganshin

Цитата:

наглядней будет выводить

наверное да.
Ещё интересно, что в режиме -m2 -t что скорость сжатия выше, чем скорость тестирования

Добавлено:
это с sf статистика или с .org ?

Цитата:

Ещё интересно, что в режиме -m2 -t что скорость сжатия выше, чем скорость тестирования

и всегда такой была - это особенность ST4


Цитата:

это с sf статистика или с .org ?

sf. на .org надо самому логи парсить

добавил в http://www.haskell.org/bz/arc1.arc freearc-installer.sfx. делает всё, как я предложил, только файлы пока не удаляет

кстати, ещё одна полезная ссылка: http://www.haskell.org/bz/unarc.exe