» FreeArc (часть 4)

Цитата:

Методы начиная с m97 вылетают с нехваткой памяти, т.к. сам Freearc 32 битный.

Дело не хаскеле ?

gryhov
понятно, но сама суть delta очень интересная. Будем тестировать.

muzf

Цитата:

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

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

или по тексту в этом топике искать

Bulat_Ziganshin
Когда можно будет ожидать очередную версию?

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

RuS_UA, FreeArc — планы на будущее, Новости. По первой ссылке видно, что скорее всего - Декабрь 2011 (недолго осталось).

---

Настройки->Шифрование->Профиль шифрования, как можно очистить историю сохраняемых профилей? Там сохраняются пути к файлам ключам, что немного напрягает. В "Файл-ключ" (выпадающее меню) тоже самое.

muzf
-ma-

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

Цитата:

как можно очистить историю сохраняемых профилей?

только вручную в freearc.ini

Bulat_Ziganshin
Благодарю за наводку! Разобрался, редактировать ini-файл нужно тот, который лежит в c:\Users\UserName\AppData\Roaming\FreeArc\ , я пытался править тот, что в Program Files... Сейчас настрою под себя, скопирую в другое место, что бы при запуске батника скидывать настройки, а не править каждый раз "ручками".

Булат, так всё таки, какой принцип работы детекта типа файла ? В каких случаях его отключение через -ma- может ухудшить сжатие ?

И ещё, возможно ли при создании очень большого архива через --sync как-то прервать процесс, и затем продолжить его заново снова через -sync ?

А мможна сделать в freearc когда создаешь архив с внешними компрессорами то они добавлялись в архив а при распаковывании добывались около архива и тогда распаковывался сам архив. В версии 0.70 в архиватор будет интегрирован среп?

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 чтобы увидеть какой файл сжат какими алгоритмами

Stalqer
1. Прочитай FAQ по FreeArc (4-й вопрос)
2. Прочитай Планы дальнейшего развития (Версия 0.75)

Добавлено:
Bulat_Ziganshin

Цитата:

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

Новый вариант:


1508 Queue operations across multiple FreeArc copies=Эта опция позволит поочередное выполнение\nопераций (упаковки, распаковки, восстановления\nархива и т.д.) даже при одновременной работе\nнескольких копий FreeArc. Таким образом, они не будут мешать друг другу полностью использовать\nресурсы компьютера и, как правило, выполнятся\nбыстрее.

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

Bulat_Ziganshin

Спасибо за хорошую работу! Единственное opensource-решение, позволяющее настроить необходимый и достаточный бэкап за определенный период. Разностные архивы 7zip куда хуже в этом плане, потому что растут.

Разрабатывая бэкап документооборота, столкнулся со странным (для пакетной работы) поведением консольной версии 0.666. Так, некоторые ошибки ключей не фиксируются в логе, задаваемом --logfile, а выводятся в stderr, после чего arc возвращает скрипту код 1 (предупреждения)

Например, отсутствие файла исключений, задаваемого ключом -x@filename

C:\BACKUP>arc a bak bak -x@arc
arc.EXE: arc: open: does not exist (No such file or directory)

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

Задание времени ключом -ta приводит к ошибке

C:\BACKUP>arc a bak bak -ta >> arc
arc.EXE: user error (Time.toClockTime: invalid input)

C:\BACKUP>arc a bak bak -ta0 >> arc
arc.EXE: user error (Time.toClockTime: invalid input)

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

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

muzf
кстати, раз возник интерес к теме - добавил в http://freearc.org/download/research/utils.zip утилиту mmdet.exe, вызывать mmdet.exe -det filename

Добавлено:

Цитата:

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

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

Ну да, на логе в UTF-8 показало что текста мало:
File size: 36174875
64kb blocks detection in 0.160 sec:
default 538
$text 14
Entire file detection: default in 0.147 sec

Есть файл весом 5,17 гб. Как его можно разбить на 2 или три архива?

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

Ololo77

Цитата:

На сегодняшний день в FreeArc отсутствуют следующие возможности, доступные в RAR и 7-zip: поддержка многотомных архивов, 64-битная версия, поддержка расширенных атрибутов NTFS, BCJ2, сегментация данных.

паковать в 7z например.

slech
Спасибо, буду пробовать.

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

Извините за мою лень, но не могли бы подсказать как сжимать при помощи FreeArc данные, поступающие из stdin ?
Конкретно требуется:
flashnul 2 -S - | arc.exe "что еще не пойму"
т.е. хочется забекапить данные с физического диска 2, сжав их freearc-ом.

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

"Извините за мою лень, но не могли бы подсказать как сжимать при помощи FreeArc данные, поступающие из stdin ? "

flashnul 2 -S image ; arc.exe a image image...

Типа так?

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

чё то 0.7 версию обещали скоро, но потом всё заглохло как то.

KurshakovIS
К чему лить воду?

Вопрос БЫЛ вполне конкретно озвучен:
может ли FreeArc сжимать данные поступающие из stdin ?


Код: arc a x -si
arc: Cmdline.hs:(829,23)-(832,59): Non-exhaustive patterns in case

хе-х.привыкай. :-\

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

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


Цитата:

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

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


Цитата:

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

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


Цитата:

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

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

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