Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор

Модерирует : gyra, Maz

Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

   

Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FreeArc
бесплатный open-source архиватор для Windows и Linux,
сочетающий высокую степень сжатия и большой набор возможностей

Официальный сайт
Документация он-лайн на консольную версию
Скриншоты / Документация на GUI версию
Страница загрузки
Проект на SourceForge.net / SVN-репозиторий

Последний релиз - FreeArc 0.40 от 1 января 2008 г. Новая версия включает мультимедиа-сжатие, улучшение обычного сжатия, сверх-быструю упаковку в режимах -m1/m2, поддержку произвольных внешних упаковщиков, настраиваемых в arc.ini, 1.5-кратное увеличение скорости работы на 2-ядерных процессорах, навороченное шифрование, полностью работающие плагины для FAR/TC, прямой доступ к архивам в интернете, восстановление архивов через интернет и множество других изменений (полный список)
 
Текущая альфа версия 0.50 от 23 июня 2008 г. Включает GUI с русификацией (описание), автоматическое определение типов файлов, создание SFX, ускорены режимы -m3/m4 и linux-версия, решены проблемы на машинах с 2+ гб ОЗУ, исправлены ошибки в -m1 и -mx (полный список изменений)

MiniFAQ...

Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Планы дальнейшего развития... (обновлены 15 июня)
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Что подразумевается под "интеграцией с Explorer"  
FreeArc wiki (включая описание формата архива)
External compressors Power Pack
Логотип - объявляется конкурс на иконки для FreeArc

Сторонние оконные программы для работы с FreeArc
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip – менеджер архивов с поддержкой большого количества форматов, для Windows и Linux

предыдущая версия шапки

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 12:55 13-08-2007 | Исправлено: juvaforza, 20:57 28-01-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
встречайте новую альфа-версию! http://www.haskell.org/bz/FreeArc-0.50-win32-alpha-2008-05-15.exe
 
Главные изменения по сравнению с предыдущей альфа-версией от 8 февраля:
* Улучшено авто-определение типов файлов
* Улучшены режимы сжатия -m3/m4
* Появилась зачаточная поддержка скриптов на Lua (см. каталог scripts)
* -di+% для вывода на экран статистики по памяти
* Настройки lzma по умолчанию изменены; добавлен matchfinder ht4, позволяющий
    создавать архивы со словарём до 1гб; параметр :h позволяет изменять размер хеша
* GUI: Научили понимать кнопку BackSpace для возврата на уровень выше
 
 

Цитата:
за более быстрый

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:50 15-05-2008
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

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

Ага, в связи с этим есть вопрос/предложение.
 
Версия 0.50 - даёшь GUI!
 
    * .........
    * доделать archive recovery, чтоб было не хуже чем в rar
 
Версия 0.80
 
    * ..........
    * Reed-Solomon codes for data recovery
 
Может есть смысл сразу делать data recovery на основе Рида-Соломона, а не в два этапа ? Потому что на момент появления многотомных архивов в 0.60 уже хотелось бы иметь полноценное восстановление данных.
 
 
 

Всего записей: 6852 | Зарегистр. 01-10-2002 | Отправлено: 15:48 15-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Потому что на момент появления многотомных архивов в 0.60 уже хотелось бы иметь полноценное восстановление данных.  

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

Цитата:
если кто готов готовую схему защиты предложить - реалихзовать её будет несложно

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 16:04 15-05-2008
PAQer



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Для меня самое главное это SFX! После стабильности конечно же. Чтоб запустил и распаковал, без всяких батников и PeaZIP'ов + возможная проблема несовместимости разных версий.

Всего записей: 161 | Зарегистр. 17-12-2007 | Отправлено: 16:24 15-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Для меня самое главное это SFX

к сожалению, у разных людей разные приоритеты
 
перенёс в планах реализацию кодов Рида-Соломона назад в 0.60. заюзать такую библиотеку - само по себе будет несложно. сложности только в изменении формата recovery record обеспечивающем бронебойное восстановление какая бы часть архива ни была повреждена

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:06 15-05-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
Для меня самое главное это SFX


Цитата:
к сожалению, у разных людей разные приоритеты

SFX нужен для продвижения FreeArc в массы, иначе массы крайне не понятливые.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 17:46 15-05-2008
PAQer



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
 к сожалению, у разных людей разные приоритеты  

До конца года с SFX управитесь?
 

Цитата:
  SFX нужен для продвижения FreeArc в массы, иначе массы крайне не понятливые.

Ох... некоторые до сих пор 7-zip'у предпочитают WinRAR, а тут FreeArc. SFX реально нужная вещь. Без него популяризация архиватора пострадает.

Всего записей: 161 | Зарегистр. 17-12-2007 | Отправлено: 17:51 15-05-2008 | Исправлено: PAQer, 17:56 15-05-2008
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

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

Первое, что приходит в голову - поступать с управляющей информацией, как когда-то поступала DOS с FAT, т.е. хранить две копии в разных местах. Например, одну вначале архива/тома, а вторую - в конце.

Всего записей: 6852 | Зарегистр. 01-10-2002 | Отправлено: 17:54 15-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
До конца года с SFX управитесь?

надеюсь  я думаю, это примерно неделя чистой работы
 
Добавлено:

Цитата:
т.е. хранить две копии в разных местах

ага. и если повредить два байта, то она тоже окажется ненужной. ероме того, есть ещё вопрос поддержки очень больших архивов - скавжем на архив в 10 гб может сохраняться 100 мб recovery info. сейчас она вся хранится в памяти и записывается в конец архива, а нужно как-то разбивать её на части

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 18:00 15-05-2008
PAQer



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В принципе, для надежности, можно дополнительно создавать еще один файл, но ТОЛЬКО с рековери информацией. На манер гибридного режима с коррекционным файлом в WavPack'e

Всего записей: 161 | Зарегистр. 17-12-2007 | Отправлено: 18:29 15-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
это не имеет никакой приницпиальной разницы по сравнению с сохранением той же информации в архиве

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 18:50 15-05-2008
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Если в архиве повреждена _только_ управляющая информация кодов восстановления, то ... и восстанавливать, в общем-то, ничего не нужно.
Да и у самих кодов ведь есть предел количества восстановимых ошибок.
 
Еще, как дополнение к хранению двух копий, можно попробовать генерировать информацию для восстановления самого блока восстанавливающих кодов. Т.е. получится двухуровневая система. И чем выше уровень, тем меньше объем этой самой информации.
Т.е. например при 10% для 100MB можно получить:
- 100MB - data
- 9MB - recovery level 1 (for data)
- 900kB - recovery level 2 (for recovery 1)
- 90kB - recovery level 3 (for recovery 2)
- 9kB - recovery level 4 (for recovery 3)
----
total: ~110MB
 
И, очевидно, переход к следующему уровню восстановления осуществляется только в том случае, если на предыдущем обнаружены ошибки.
 
Правда, может, с точки зрения математики, все эти навороты - полная чушь? И никакого особого выигрыша в востановлении не дают?

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 19:02 15-05-2008
Nick222

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Архивации большого количества файлов с длинными именами в планах вообще нет - или после 0.8 ?

Всего записей: 2284 | Зарегистр. 28-11-2004 | Отправлено: 19:28 15-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Если в архиве повреждена _только_ управляющая информация

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

Цитата:
И, очевидно, переход к следующему уровню восстановления осуществляется только в том случае, если на предыдущем обнаружены ошибки.  
 
Правда, может, с точки зрения математики, все эти навороты - полная чушь?

выглядит интересно. насколько это правильно - сказаить не могу, у меня тоже с математикой пробдлемы. но одна очевидная вещь вылезает - если повреждены эти 10 доп. мегабайт плюс один байт из первых 100 мб, то опять пролетаем
 
насколько я понимаю, основная идея надёжного восстановления данных - мы вам гарантируем восстановление при порче *любых* 1% (к примеру) секторов арзива
 
Добавлено:

Цитата:
Архивации большого количества файлов с длинными именами в планах вообще нет - или после 0.8 ?

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 19:29 15-05-2008
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
повреждены эти 10 доп. мегабайт плюс один байт из первых 100 мб

так это ведь выходит уже больше тех самых "любых 10%"
а если точнее, 10% + 1 байт
 
на самом деле, чтобы сделать архив не подлежащим восстановлению
достаточно повредить некоторый процент + 1 байт на каждом уровне, кроме первого, ну и, соответственно, что-нть в самих данных
что, наверное, будет гораздо меньше 10% в сумме
 
но, насколько я понимаю, в том же winrar при добавлении 10% избыточности, не гарантируется восстановление при повреждении 10% - т.е. пользователь управляет размером архива, а не "границей восстановимости" (которая будет, очевидно, в несколько раз меньше размера избыточности)

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 19:46 15-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
так это ведь выходит уже больше тех самых "любых 10%"  

нет. архив 10 гб, инфа для восстановления 111 мб
 

Цитата:
насколько я понимаю, в том же winrar

в том-то и дело, что rar - не пример для подражания. так, как в rar, у меня уже сделано. надо ориентироваться на программы с RS кодами типа iceecc

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:51 15-05-2008
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Из комментариев на форуме ICE ECC:

Цитата:
 
100 блоков по 1 метру могут восстановить далеко не каждые 100 мегабайт потерь, а лишь такие ошибки, которые покрываются нужным паттерном, которые можно покрыть 100 отрезками по 1 метру.  
стало быть, существуют такие 101 бит (именно бит, а не байт и не мегабайт) которые ECC не восстановит. Заметьте, не сто мегабайт, а 101 бит!!! Так что Рид-Cоломон никаких гарантий не дает.
 


Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 23:49 15-05-2008
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
sabio

Цитата:
Заметьте, не сто мегабайт, а 101 бит!!! Так что Рид-Cоломон никаких гарантий не дает.

Дык ведь задача не в создании "абсолютной" системы восстановления битых архивов. Это невозможно. Достаточно, чтобы в FA было надежнее, чем в WinRAR.

Всего записей: 6852 | Зарегистр. 01-10-2002 | Отправлено: 00:07 16-05-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ещё раз повторю - используемая в iceecc схема гарантирует восстановление при потере любых 100 *блоков*. на магнитных носителях летят целые сектора, а не отдельные биты, так что это удовлетворительное решение
 
Добавлено:

Цитата:
Дык ведь задача не в создании "абсолютной" системы восстановления битых архивов. Это невозможно. Достаточно, чтобы в FA было надежнее, чем в WinRAR.

есть 2 задачи:
1. заюзать РС для увеличения надёжности восстановления. сейчас достаточно запороть всего два блока, находящихся на расстоянии N друг от друга, где N - объём recovery record, чтобы восстановление стало невозможным. afaik та же фигня и в rar. использование РС позволит восстановить сбои в любых N блоках данных
 
2. сделать такую систему хранения RR чтобы сбой *любых* N блоков архива можно было компенсировать, включая сбои в самой RR. кроме того, надо разобраться с хранением RR в очень больших архивах - надо её записывать кусками ограниченного размера
 
ну и ещё есть 0. искать каталоги в сбойных архивах по сигнатуре, чтоб можно было вытянуть хотя бы уцелевшую часть архива. к RR это прямого отнощшения не имеет, но без этого восстановление архивов остаётся больше бумажной фичей
 
Добавлено:

Цитата:
SFX нужен для продвижения FreeArc в массы

перекинул это назад в планы на 0.50
 
кстати, если здесь есть С-порграммисты - эту часть можно сделать без меня. на самом деле sfx у нас уже есть  нужно сделать только две вещи чтоб его реально можно было использовать:
 
1) добавить многопотчность для распаковки цепочек алгоритмов сжатия типа exe+lzma
2) сделать GUI-версию на чистом win api или какой-то leightweight библиотеке - сейчас есть только консольный sfx
 
каждая из этих задач при наличии соответствующей кваликации потянет, я думаю, дня на 3

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:07 16-05-2008
Ghost2004

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Насчёт новых настроек lzma - потестировал немного, вот что вышло:
 
Исходные данные: образы игрушки и её же самой, но с аддоном. Разбиты на 6 равных кусков каждая, чтобы полные совпадения практически полностью влезли в словарь на 1000mb. Полный размер -  9 094 430 834 байт.
 
lzma:1000mb:max:ht4:mc32 - 3 298 916 060 .  
Время сжатия - 17634.30 с, скорость 516 кб/с. Полное время - 19077.95 с.
Но при этом rep:128 выдаёт лучшие результаты (время не запомнилось - но оно  
наверняка соответствует скоростьям 15-20 Мб/с):
 
rep:1000mb:128:h27 - 3 298 640 599
rep:1000mb:128:h27++rep:1000mb:128:h27:a99 - 3 121 331 796
 
Так что либо mc32 тут не хватает, либо rep:128:1000mb+lzma:max:bt4:192mb таки оказывается эффективней. Единственное что несколько мешает этому варианту, так это глюки выделения памяти с tempfile - к сожалению, такая цепочка не проходит, приходится делать двойной архив.  
 
Кстати говоря, интересно, это заморочки 32-битных виндов, или для 64-битных систем что-нибудь вроде rep:1500mb+tempfile+rep:1500mb или rep:1500mb+tempfile+lzma:192mb:max пройдёт?
 
Далее,
rep:1000mb:128:h27++lzma:192mb:max - 2 679 724 040
rep:1000mb:128:h27++lzma:1000mb:max:ht4:mc32 - 2 568 654 628
 
(далее для упрощения буду вместо rep:1000mb:128:h27++rep:1000mb:128:h27:a99 писать rep:1000mb:128x2)
 
rep:1000mb:128x2++lzma:1000mb:max:ht4:mc32 - 2 532 449 817  
rep:1000mb:128x2++lzma:192mb:max - 2 531 091 310  
 
Так что выходит, на этих данных (т.е. после одного rep'а) rep:1000mb:128:h27++lzma:192mb:max чуть лучше rep:1000mb:max:ht4:mc32 .
 
А вот для самой последней версии я поигрался с настройкой :h - вот что вышло:
rep_1000mb_128x2++lzma:64mb:128:max:h1gb :
 
Compressed 1 file, 3.121.331.796 => 2.536.560.520 bytes. Ratio 81.2%
Compression time 4067.89 secs, speed 767 kB/s. Total 2740.00 secs
 
rep_1000mb_128x2++lzma:64mb:128:max
 
Compressed 1 file, 3.121.331.796 => 2.536.562.893 bytes. Ratio 81.2%        
Compression time 4594.49 secs, speed 679 kB/s. Total 4615.69 secs
 
Так что за счёт такого увеличения расходуемой памяти размер хоть и почти не меняется, но ускорение заметное - в районе 13% для одного процессорного ядра, и целых 70% для двух ядер.
 
В связи с этим вопрос - каким образом выделяется память при использовании :h - нельзя ли сделать возможным выделить к 1 Гб словаря больше 512 mb хэша (ведь выходит, что выделяется dictsize*1.25+hashsize), если свободные блоки памяти - один на 1750 mb, другой - 750 mb? Ведь такая настройка должна заметно ускорить или даже улчшить сжатие при наличии 3 Гб памяти.

Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 15:56 16-05-2008
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор
Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru