» FreeArc (часть 4)

TIS456
Ну зачем Вам мнение автора?! Как захотел - так и назвал (пронумеровал). Он - АВТОР.
Один из итальянских суперкаров (из всемирно известных) назывался "Дьябло". Никого на кол не сажали. Дык, там вообще, Ватикан "под боком".
Конечно, при виде такой машины, DimmY упал бы в религиозно-эстетический обморок.
Машина была далеко не "фривэйр", нормально продавалась и фото ее обошли все дюже глянцевые издания мира.
Кстати, встречали программы на арабском языке, где сразу, при открытии, текст из Корана? Представьте ситуацию: открывает глубоко верующий от ислама ..ну .. архиватор и не видит этого самого текста из Корана. Он что, сразу автора к ответу должен призывать? Чтобы тот публично объяснялся?

P.S. Автора (и всех его сотрудников) Daemon Tools - костром инквизиции очищать нужно?
Он тоже "шуткой юмора" увлекается.

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

Цитата:

планируете ли вы улучшить поведение прогресбара?

нет. это невозможно для внешних архиваторов, не использующих stdin/stdout

Есть ли смысл в опции mode=7z,winrar.
Что бы FA можно было передать строчку от 7z например и он с ней прекрасно работал или от Winrar.
Т.е. для перевода скриптов на FA было бы достаточно изменить путь запуска архиватора и добавить опцию mode.
Это конечно для ленивых, но всё же.

Bulat_Ziganshin
precomp + FA
при включении в алгоритм прекомпа сжатия сейчас проходит так:
1) файлы которые должны обрабатываться этим препроцессором загоняются в архив без сжатия
2) файл обрабатывается прекомпом
3) далее идет упаковки lzma

не лучше было бы сделать этот процесс следующим образом:
1) прекомпом обрабатывается каждый нужный файл отдельно
2) далее идет упаковки lzma

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

преимущества такого метода:
1. выпадает объединения данных в несжимаем архив (+ скорость, - размер временной папки при упаковке / распаковке)
2. при параллельной работе размер папки с временными файлами будет минимальный (будет равен наибольшему pсf файлу)
3. этот процесс позволит сделать лучше поведение прогресс бара

возможно ли такое вообще сделать, и если возможно, то вы не хотите ли это сделать в ФА?

slech
программа изначально ориентировалась на макс. совместимость с rar по ком. строке, именно из-за названных тобой причин. в доке есть даже раздел, где перечислены все несовместимости, хотя кое-чего там не хватает. я собираюсь исправить некоторые проблемы совместимости, в частности обработку *.*, указание каталогов, -ag, -ap

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

Цитата:

С этим к доктору.

давай обойдёмся без этого

ответ - да, шутка. а какие ещё варианты - что я сатанист?

как бы не говорили но ВинРАР при его относительной "древности" все таки умудряется хорошо сжимать
(хотя странно что версия 4,0 бета при упаковке все равно пишет что базовая версия для распаковки 2,9,
в чем тогда причина появления 4 РАРА не понятна)
может это уже говорилось, но GUI не хватает drag&drop

заметил странность в работе архиватора
при распаковке архива ( около 1 гига бэкапа БД MS SQL сервера) в самом конце выводилось предупреждение о ошибке целостности данных
однако винрар без проблем распаковывал этот архив
(архив делается zlib level 9 через nnbackup)

Обнаружена следующая проблема.

Система стоит на диске С с FAT32.
На диске D лежит снимок диска C в формате tib, размер 9 ГБ.
Архивация FreeArc невозможна по той простой причине что он на диске C зачем-то начинает создавать временный файл более 4ГБ. Изменить временную директорию не нашел как и вообще не понятно зачем такой огромный временный файл и может его как-то разбивать.

kalpak

Цитата:

может это уже говорилось, но GUI не хватает drag&drop

говорилось

Булат, спасибо за ответ. Спасибо ответившим, вопрос закрыт, уже как офф-топ пошел. Замечу момент - где-то читал, что Майкрософт у себя что-то из продуктов пропустили под номером 13 (не скажу сейчас точно) и еще кто-то из производителей ПО. У них это по всей видимости вопрос маркетинга, который к опенсорсу конечно имеет весьма меньшее отношение.

З.Ы.: если брать сам вопрос о символах, как большой вопрос для обсуждения, то он конечно за пределами ветки, у каждого свое отношение к сфере символов, где нужно, люди это обсуждают

1. Двойник программы WinRK не только меня попутал, такое было и ранее:
http://forum.compression.ru/viewtopic.php?f=5&t=405

2. Проблема с FreeArc 0.666
Тестировал сжатие разными методами папку: 1,12 ГБ, 1000 файлов, 79 папок
Методы
-mex7
-mex8
-mex9
-mex9 -ld1600m
При тестировании, через несколько секунд (какие-то предварит. подготовки, процессбар еще не идет) процесс останавливался и появлялась надпись:
ПРЕДУПРЕЖДЕНИЕ: невозможно выделить память, необходимую для (рас)паковки в 4х4:b7mb:ppmd:16:384mb:c7mb

Методы
-mex6 и ниже
-m9
-mx
тестируются нормально.
Память 4 ГБ, проц - i3-530, Win7 32-разрядная.

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

Или это лечится в новой альфе:
http://forum.ru-board.com/topic.cgi?forum=5&topic=31386&start=2080#7
Где взять гуе-версию от 17 ноября?
Здесь последняя?
http://forum.ru-board.com/topic.cgi?forum=5&topic=31386&start=0&limit=1&m=1#1

Майкрософт из той самой страны, где Аполлон (чудом вернувшийся) с "неправильным" номером взлетел в "неправильный" день, в "неправильное" время и .. с площадки, с трижды "неправильным" (39 т.е. 13*3) номером. (!!!)
НАСА впала в мистический трепет. Они тоже изъяли "плохие" номера и прочее.
Предположение - появилась традиция.

P.S. Я прикалывался, когда читал выдержки воспоминаний астронавта того Аполлона. Он долго и безуспешно пытался заставить работать какую-то аппаратуру (ну, происки "лукавого"!). Никак. Тогда, сказал астронавт: "я применил к нему "русский метод". Т.е. кулаком. Заработал!
От себя: "лукавому" не нравятся силовые приемы. Обычно, в процессе, принято произносить "производственную молитву", где упоминается вся родословная прибора, включая его разработчиков. Тогда, эффект "русского метода" становится выше.

1. ну, я потому и сообразил сразу
2. проверь плиз с ноябрьской альфой, я там как раз этого рода проблемы исправлял

Добавлено:

Цитата:

Здесь последняя?

ага

vasulpr, спасибо. Не заметил, потому что каталог не был явно прописан (просто пусто). А предложение разбивать временный файл на меньше 4ГБ для FAT в силе.

а до х64 так понимаю еще палкой не докинуть...

Попытка добавить к архиву (2ГБ) информацию для восстановления приводит к сообщению: malloc: resource exhausted (out of memory).

Параметры сжатия: -mx -ld1600

Andruhin
да. а зачем она тебе?

Добавлено:

Цитата:

при распаковке архива ( около 1 гига бэкапа БД MS SQL сервера) в самом конце выводилось предупреждение о ошибке целостности данных
однако винрар без проблем распаковывал этот архив
(архив делается zlib level 9 через nnbackup)

а что скажет 7-zip? я его бибилиотеку использую

Цитата:

а какие ещё варианты - что я сатанист?

Хм.. Я установил FreeArc (злосчастный билд 0.666! ) себе и ещё нескольким людям и потому хочу спросить - что теперь будет и возможно ли предпринять какие либо очистительные процедуры?

P.S. Наверное офтоп? Если кто захочет помочь, то отвечайте пожалуйста здесь.

Sergey_Advisor

1. А без восстановления с опцией -mx на 9 ГБ у Вас что получается?
Это же уйма времени! (1 час?)

2. Не пробовали что-нибудь типа -m82...-m83
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6
Временные файлы в этих методах не создаются.

win 7 x64, офис 2010 x64, 7zip x64... вобщем из спортивного интереса...

Может, тут смогут ответить на этот вопрос?

Цитата:

2. проверь плиз с ноябрьской альфой, я там как раз этого рода проблемы исправлял

Проблема с тестированием ушла. Теперь все тестится успешно.
Но есть другие непонятки уже при распаковке:
1. Если при распаковке длинный путь, например
D:\Проба\Теория Электрических Цепей (ТЭЦ)
то распаковка при достижении 79% заканчивается окном с длинным сообщением (не знаю, как прикрепить скрин) "....(No such file or directory)"
2. Если путь короткий
D:\Проба\
то распоковка проходит нормально до конца.
Какие-то проблемы с длиной каталогов?

Это не зависит от метода: -m9, -mex9

Добавлено:
Что касается архивирования этой же папки.
750 МБ, 1925 файлов, 398 папок. FreeArc 0.67 от 17 ноября 2010

На компьютере с процессором Е6750 WinXP
-mex9 4м01с 187 696 723 Байта
-m9 4м02с 186 508 729 Байтов

На компьютере с процессором i3-530 Win7 32-разр.
-mex9 2м06с 187 696 398 Байта
-m9 2м46с 186 511 187 Байтов

Почему разница во времени небольшая для i3-530 и совсем нет для E6750?
Из-за WinXP?

На компьютере Е6750 WinXP у программы 7z 9.20 эффект чувствуется:
Ultra LZMA2 2thz 4м52с 201 637 554
Ultra LZMA2 1thz 6м59с 201 327 366

Время там 1,5 часа меня устраивает.
С временным файлом я разобрался - перекинул его на диск с NTFS, но все равно осадочек остался.
А вот почему добавление кода для восстановления упирается в память мне не понятно - ведь код добавляться по верх основного архива и по идее степень сжатия основного архива ни как влиять не должна. С -mx -ld800 код все таки добавился.

подскажите, какой параметр лучше использовать для rep, чтобы файл сжать максимально?

мой -m9 - это как раз 2 потока. -mex9 использует сколько угодно потоков, эффект становится заметен начиная с 4 ядер

Добавлено:

Цитата:

Если при распаковке длинный путь

общая длина имени файла не должна превосходить 255 символов

Булат, а как бы к вам в статистику попасть ?
Тут на днях побывал на сервере с 70 Гб памяти, хотел украсить вашу статистику

1. При архивировании папки 1,12 ГБ, 1000 файлов, 79 папок. FreeArc 0.67 от 17 ноября 2010:

На компьютере с процессором i3-530 Win7 32-разр.
-mex9 4м28с 821 695 КБайта
-m9 10м29с 824 329 КБайтов

Но ядер-то два - почему разница? Играет роль, что их псевдочетыре?

Примерно то же самое при -m6 и -mex6.
-m5...m8 и -mx тоже двухпоточные?

2. Обратил внимание, что в справке по архиву есть информация о необходимом ОЗУ для распаковки. Очень хорошо! У WinRAR и 7zip такого нет!