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

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

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

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152

Открыть новую тему     Написать ответ в эту тему

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Часть 1 | Часть 2 | Часть 3


Скачать последний релиз - FreeArc 0.666 от 20 мая 2010 г. Что нового: ускорение работы в 1.5-2 раза благодаря новой технологии многопоточного сжатия, распаковка архивов многих форматов используя технологии 7-zip, запуск файлов из архива, исправлены все проблемы интеграции с Explоrer (подробнее)
Текущая альфа версия: 0.67 - загрузка | список исправлений | блог


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


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


Родственные темы:
Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах
ISDone.dll - библиотека распаковки архивов в инсталяторах
REP & SREP
Пережатиe/Pекомпрессия/Oптимизация файлов для лучшего сжатия - "а как сжать ещё лучше?"
FreeArc и Unix - для альтернативно одарённых
• репозиторий FreeArc 'Next на github.com
• тема FreeArc 'Next на форуме encode.su
• раздел FreeArc на форуме krinkels.org

 
Другие архиваторы:
WinRAR
7-zip
PowerArchiver
HaoZip
BandiZip


Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 11:36 23-11-2010 | Исправлено: Nikolai2004, 21:23 03-02-2021
egor23



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

Цитата:
p.s. кстати, что за --queue ? Внятного описания с примером найти не удалось, в единственной документации http://freearc.org/ru/FreeArc040-rus.htm не упоминается.

что нет в документации, то есть в истории версий FreeArc
http://freearc.org/history/changelog_full_ru.htm
 
или по тексту в этом топике искать
 

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 16:37 01-04-2013 | Исправлено: egor23, 16:39 01-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Поймал странность.
Есть папка с логами, *.log , попадают под $text в arc.groups.
Так вот, запись в ini  81 = / $text=ex1b сжимает сильнее, чем 81 =  rep:2gb:112:c64:d4m:s64+xtor:3:4m:h32k / $text=ex1b . Казалось бы, раз задано $text=, то всё что до этого должно игнорироваться, и итоговый размер должен совпадать. Но он не совпадает!

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 00:19 02-04-2013
Bulat_Ziganshin

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:21 02-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Можно чуть чуть поподробнее ?
-maLEVEL - set filetype detection LEVEL (+/-/1..9)
Описания этой опции в старой документации нет.  -ma- снижает уровень детектирования расширения файлов, можно на пальцах рассказать что это значит ? Сейчас неправильно определился тип файлов (не по расширению) и он попал не в $text ? Есть ли режим verbose или debug у Freearc, чтобы увидеть как детектируется каждый файл и в какую секцию попадает ?

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 09:21 02-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Булат, так всё таки, какой принцип работы детекта типа файла ? В каких случаях его отключение через -ma- может ухудшить сжатие ?
 
И ещё, возможно ли при создании очень большого архива через --sync как-то прервать процесс, и затем продолжить его заново снова через -sync ?

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 11:08 04-04-2013
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
muzf
freearc 0.50+ по умолчанию пытается определить тип файла по его содержимому. если файл похож на текст - его принудительно записывают в группу $text, несжимаемые данные - в группу $precomp или $compressed. вот кусочек кода:
 
    // Тип данных: $precomp/$compressed если не сжимается ни order-0 ни lz77.
    //             $text если активных символов от 17 до 80, число повторов дистанций невелико и lz-матчи составляют хотя бы 10% данных
 
те, кто не попали под эти эвристики, остаются в старых группах (определённых по arc.groups)
 
-ma- отключает это, -ma1..9 равноценны (в будущем предполагается на более высоких уровнях выполнять более тщательный анализ)
 
включить весь возможный вывод можно опциями -di -di+$ -i2 (опции -di именно в таком порядке). можно также сопоставить вывод команд l и lt чтобы увидеть какой файл сжат какими алгоритмами

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:17 04-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Теперь понятно в чём была проблема, эти логи, которые я сжимал, содержали много русских букв, причём в UTF-8, поэтому не попадали в $text. Причём PPMd (xppmd:12:192m
) их всё равно сжимает лучше и быстрее чем всё остальное.
Может UTF-8, а также тексты с русскими буквами тоже принудительно записывать в группу $text ?

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 13:43 04-04-2013
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
muzf
кстати, раз возник интерес к теме - добавил в http://freearc.org/download/research/utils.zip  утилиту mmdet.exe, вызывать mmdet.exe -det filename
 
Добавлено:

Цитата:
Может UTF-8, а также тексты с русскими буквами тоже принудительно записывать в группу $text ?
 

а спрашивать русские это буквы или татарские, предполагается у пользователя?

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:02 04-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ну да, на логе в UTF-8 показало что текста мало:
File size: 36174875
64kb blocks detection in 0.160 sec:
  default 538
  $text 14
Entire file detection: default in 0.147 sec

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 14:34 04-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Обнаружил серьёзный недостаток режима --sync - создаётся копия файла с изменениями/добавлениями.
Это сразу рубит на корню идею бэкапа, когда например один раздел бэкапится на другой носитель такого же объёма, и лишнего пространства под временный файл просто нет.
Жаль, хотелось бы чтобы все изменения были с одним файлом. Не знаю как этом случае будет удаление части файлов из сотни-гигабайтного архива без передвижения всей остальной части, но в dynamic VHD или sparse file это как-то делается. Говорят что NTFS supports hole-punching, с помощью функции DeviceIoControl() (например это умеет утилита http://www.opalapps.com/sparse_checker/sparse_checker.html ), цена этого - фрагментация файла, но для бэкапов это неважно. Похожий эффект можно добиться с помощью флага NTFS Compression, если заполнять неиспользуемые области нулями.

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 23:47 05-04-2013 | Исправлено: muzf, 00:13 06-04-2013
MSx213



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Burat нашел один баг. Когда делаю бекап папки с параметром -ep3 - архив пакуется. Я в него через FA захожу там первый каталог буква диска, захожу в этот каталог и FA уже переходит физически на реальный диск, т.е. отображает каталоги не из архива, а содержание реального диска. И добраться до файлов в этом архиве не представляется возможным)

Всего записей: 203 | Зарегистр. 25-02-2007 | Отправлено: 02:07 06-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
--volume=SIZE несовместима с --sync ?
Эта опция могла бы стать выходом. Например обновлялись бы только те куски, в которых были изменения (удаление/добавление/изменения), причём небольшой размер куска позволял бы обработать ситуация, когда из источника удаляется большая часть файлов и заменяется новой, а на приёмнике нет места для пересоздания всего архива.

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 00:28 07-04-2013
terenty79

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
чё то 0.7 версию обещали скоро, но потом всё заглохло как то.

Всего записей: 1154 | Зарегистр. 26-02-2006 | Отправлено: 00:50 07-04-2013
Evgenii66

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
хе-х.привыкай. :-\

Всего записей: 78 | Зарегистр. 22-02-2009 | Отправлено: 05:31 07-04-2013
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
muzf
дописывать новые данные в конец существующего файла из всех известных мне архиваторов умеет только zpaq, плюс в нём дедупликация и поколения файлов, так что рекомендую для бекапов
 
или классически - один архив с базовой версией, плюс дополнительные для инкрементов
 

Цитата:
Ну да, на логе в UTF-8 показало что текста мало:  

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

Цитата:
Burat нашел один баг.

спасибо, записал
 

Цитата:
--volume=SIZE несовместима с --sync ?  

-v не работает с arc-архивами, а 7-zip если и обновляет многотомники, то создаёт новые копии
 
terenty79
пока идёт работа над переводами

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 12:28 07-04-2013
juvaforza

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

Цитата:
пока идёт работа над переводами

В примере меню нужно пару строк (19 и 62) обновить

Всего записей: 2895 | Зарегистр. 26-11-2005 | Отправлено: 13:13 07-04-2013
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SREP 3.2 (6 апреля 2013 г.)
  • -m2 -lN теперь эквивалентно -m3 -lN -cN: степень сжатия посередине между -m1 и -m3, а скорость как у -m2 в прежних версиях
  • -a0: та же степень сжатия как при -a1, памяти требуется на 5-10% меньше, но в 1.5-2 раза медленней
  • -a32/-a64: с large pages обычно ещё быстрее чем -a16, но требует ещё больше памяти
  • -slp[+/-/]: форсировать/отключить/попробовать(по умолчанию) использовать large pages, т.е. страницы виртуальной памяти в 2-4 мб

Мелкие изменения:
  • -v[0..2]: уровень детализации выводимой информации
  • -pcMAX_OFFSET: выводит внутренние счётчики производительности только для матчей ближе чем MAX_OFFSET
  • -l64k/-c1mb - поддержка нового синтаксиса (суффиксы k/m/kb/mb для обозначения килобайт/мегабайт)
  • 32-битная и 64-битная версии откомпилированы GCC 4.7
  • 32/64-битные динамические и статические (-static) компиляции под Linux

 
 
 
SREP 3.2 (April 6, 2013)
  • -m2 -lN now is the same as -m3 -lN -cN: compression ratio is average between -m1 and -m3, while speed is the same as in old versions
  • -a0: the same compresssion ratio as -a1, memory usage is smaller by 5-10%, but 1.5-2x slower
  • -a32/-a64: sometimes faster than -a16 (only with large pages), but needs even more memory
  • -slp[+/-/]: force/disable/try(default) large pages support

Minor changes:
  • -v[0..2]: verbosity level
  • -pcMAX_OFFSET: print performance counters for matches closer than MAX_OFFSET
  • -l64k/-c1mb syntax support (k/m/kb/mb suffixes for kilobytes/megabytes)
  • Both 32-bit and 64-bit default executables are compiled with GCC 4.7
  • 32/64-bit dynamic/static linux builds

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:21 07-04-2013 | Исправлено: Bulat_Ziganshin, 13:24 07-04-2013
muzf

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

Цитата:
я попробовал и на логах, и худтекстах в utf8 - детектятся как текст. могу предположить что у тебя много строчек одинаковой длины  

Да, есть такое, бывает 5-10 строк подряд одинаковой длины.
 

Цитата:
или классически - один архив с базовой версией, плюс дополнительные для инкрементов  

С удовольствием бы, но ситуацию "удалил 300гб и записал 300гб новых данных" это не обработает, так как место на источнике и приёмнике примерно одинаково, и эти удалённые 300гб не очистяться.

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 00:33 08-04-2013
muzf

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arc.exe умеет сжимать каждый файл в отдельный архив, и при --sync перепаковке менять только те которые изменились ?

Всего записей: 147 | Зарегистр. 23-11-2007 | Отправлено: 15:03 16-04-2013
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Один товарищ разработал библиотеку для распаковки архивов FreeArc в NSIS: http://www.smart-arab.com/2013/04/freearc-for-nsis-plugin/
 
или на офсайте: http://nsis.sourceforge.net/FreeArc_plug-in
 
muzf
попробуй - наверно получится

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:34 17-04-2013 | Исправлено: Bulat_Ziganshin, 12:08 21-04-2013
Открыть новую тему     Написать ответ в эту тему

Страницы: 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 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc (часть 4)


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru

Рейтинг.ru