» FreeArc (часть 4)

Замечание к прогрессу: (в текущей версии 0.666)
% вычисляется через количество файлов а не объем ими занимаемый (по крайней мере при сортировки по размеру это очень заметно)
Из это следует 3 беды:
- собственно % очень оптимистичный
- время выполнения почти постоянно увеличивается или стоит на месте
- ну и предполагаемый объем архива очень оптимистичный (я сначала так радовался)

Добавлено:
Только что помогал админу настроить резервное копирование.
От сюда Идея!

Сделать опцию "архивировать только файлы которые изменились за последние n дней"

Цитата:

с версией SuperREP 3.0 (Jan 30, 2012) проблем нет

у меня получилось следующее:

с srep 3.0 этот архив распаковать невозможно:


Код: M:\11>arc t data.arc
FreeArc 0.67 (March 15 2014) testing archive: data.arc
Testing 113 files, 54,676,790 bytes. Processed 0%
Unpacking 36,437,086 bytes with srep -d -s $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

ERROR! Incompatible compressed data format: v2098180 (this program supports only v1..v3) in file $$arcpackedfile$$.tmp

Errorlevel=4

ERROR: invalid compression method or parameters in srep

Цитата:

От сюда

пишется слитно


Цитата:

Сделать опцию "архивировать только файлы которые изменились за последние n дней"

Суперидея - прочесть доку


Цитата:

% вычисляется через количество файлов а не объем ими занимаемый (по крайней мере при сортировки по размеру это очень заметно)

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


Цитата:

- ну и предполагаемый объем архива очень оптимистичный (я сначала так радовался)

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

[more] 1 тест srep3.0_x86_30-01-12

Код: FreeArc 0.67 (March 15 2014) creating archive: С:\ARC\data.arc
Compressing 114 files, 54,676,790 bytes. Processed 0%
Compressing 54,676,790 bytes with srep -m3 -l512 -c256 -a1 $$arcdatafile$$.tmp $
$arcpackedfile$$.tmp
SREP 3.0 (January 30, 2012): input size 52 mb, memory used 36 mb, -m3 -l512 -c25
6 -a1
100%: 54,676,790 -> 35,971,447: 65.79%. Cpu 96 mb/s, real 77 mb/s

Errorlevel=0
Compressed 114 files, 54,676,790 => 15,565,150 bytes. Ratio 28.47%
Compression time: cpu 22.11 sec/real 13.28 sec = 166%. Speed 4.12 mB/s
All OK

All done.

Bulat_Ziganshin

Ну такой вид, так такой.
Достаточно неплохо. Однозначно лучше текущего.

Diana_Kovalenko
да, ошибка возникает от сочетания опций -l512 -c256. я посмотрю, а вам советую заменить "-m3 -l512 -c256" на -m5

Булат, а не мог бы ты добавить ключик на запуск в свёрнутом (background) режиме? При чём, чтобы фокус не перебивался: кнопка на таскбаре просто появляется и всё.

Запуск при помощи "start /min" ворует фокус.

З.Ы. Если уже есть такое - извиняю, подскажите.

Цитата:

советую заменить "-m3 -l512 -c256" на -m5

Bulat действительно с этим параметром srep3.93a_beta_x86_11-10-14 работает безукоризненно.

Спасибо большое и дай бог вам крепкого здоровья!

Цитата:

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

Булат, есть ли уже на данный момент решение этой проблемы (сжатие открытых для записи файлов в 7z)?

coolerru
а как это сделать?


Цитата:

Поставил на архивирование 1 млн. файлов (меньше 2кб с сортировкой по размеру и удалением после архивации)
Оказалось удалились не все файлы.

можно снова выполнить ту же операцию над оставшимися файлами, а затем слить два архива. другой вариант - дать команду "arc lb archive" и затем отредактировать её вывод, добавив команды del

Добавлено:
перевод инфы по последней альфе, выполненный ruduk (с моими исправлениями):

Новая альфа-версия:

Управление памятью для сжатия: теперь FreeArc знает, что 4x4/grzip может использовать больше или меньше памяти, в зависимости от числа потоков, без потери совместимости с уже сжатыми данными. Это усложняет управление памятью:При сжатии, информация "Память для упаковки 747mb, распаковки 96mb" теперь сообщает, сколько памяти использовано именно сейчас для упаковки и минимальный объем памяти, который потребуется в дальнейшем для распаковки
Диалог Сжатия показывает те же объёмы для стандартных методов сжатия
АркИнфо/lt команды показывают минимальный объём памяти, необходимый для упаковки и распаковки выбранного архива
При сжатии, -lc ограничивает использование памяти, сначала добавляя "tempfile" между методами, затем уменьшая параметры :t:i в 4x4/grzip и, в последнюю очередь, снижая объем памяти, используемый каждым потоком
При сжатии, -ld ограничивает минимальный объем памяти, который потребуется позже для распаковки (т.е. с "tempfile" между методами и настройками :t1:i0 в 4x4/grzip)
При распаковке, -ld ограничивает использование памяти, сначала добавляя "tempfile" между методами, затем уменьшая параметры :t:i в 4x4/grzip; в частности, вы можете использовать -ld1, чтобы использовать миниммально возможный объём памяти
Снижено использование памяти для xlzma распаковки на 9%; ppmd упаковки и распаковки на 14 МБ для каждого потока
LZMA: -di/lt показывают реальный размер хеша в :h (он может быть меньше, чем указано в команде, потому что каждый блок (:mc) должен содержать 2^n значений)
Исправлено множество ошибок и сделано много улучшений в управлении памятью для сжатия, теперь все показанные объемы памяти должны отражать реальное использование памяти
Остальные улучшения:Новая схема диалога прогресса, разработанная sabio и ruduk
Заглавие диалога прогресса теперь "xx% hh:mm:ss | Команда ..." вместо "{xx% hh:mm:ss} Команда ..."
i18n: полный перевод на Португальский Стандартный от Nuno Rego!
i18n: укорочены сообщения 0018, 0086, 0433, 0435, 0300, 0437, 0438, 0439, 0440, 0441, 0382, 0383, 0384, 0301, 0302. Если вы поддерживаете перевод, пожалуйста, попробуйте сделать то же самое
7z.dll: более точное вычисление dict/mem для bcj2-сжатых архивов в АркИнфо/lt
Unarc/DLL/large SFX: добавлена распаковка LZ4
Unarc.dll: добавлен C# пример использования, разработанный Mohammad Khalifa
lzma:fastest сделан набором действительно самых быстрых настроек
Осталось доделать:
Небольшие улучшения в Диалоге Прогресса
Управление памятью в Tornado и Unarc

Bulat_Ziganshin, FreeArc не переезжает ?

Bidding farewell to Google Code

insorg
сжатие у всех srep одной версии одинаково

Добавлено:
new alpha version:

compression:arc.ini: removed outdated -m#p definition (now it's inside arc.exe)
-max/-m#p/-m#j got new definitions with precomp+dispack+srep
new compression method synonyms: precomp, precompj, maxprecomp, maxprecompj, exe2, maxsrep
-m1 made faster on multimedia/compressed files
DisPack: improved x86 code detection and compression ratio as consequence
-s now is equal to "-s100k;" (was "-s20k;")

other improvements:SFX/Installer: compression by the UPX now is disabled because antivirus software scans large SFXes very slow
ArcInfo/lt: more verbose info about archive dictionaries; CompressionMemory/DecompressionMemory/Dictionary for .7z archives
-rr: -lc now obeyed when adding large RR to archive
Portuguese Standard translation was substantially improved
GUI: now text inputs in Add/... dialogs may include spaces if entire option text is surrounded with quotes, f.e.:
" %Y-%m-%d"
Date: " %Y-%m-%d"

bugfixes:LZMA-x64: fixed bug that prevented use of more than 4GB even in 64-bit version
Unarc: fixed bug with SERPENT decryption in unarc.exe/dll/sfx
GUI: bugfix: Compression checkbox in the Add dialog shouldn't be forced to be checked when the dialog is initialised or archive type is selected



Новая альфа-версия:

сжатие:arc.ini: удалено устаревшее определение для -m#p (теперь оно встроено в сам arc.exe)
-max/-m#p/-m#j получили новые определения с precomp+dispack+srep
новые удобные синонимы методов сжатия: precomp, precompj, maxprecomp, maxprecompj, exe2, maxsrep
ускорен -m1 на мультимедиа/сжатых файлах
DisPack: улучшен поиск кода x86 и как результат - степень сжатия
-s теперь эквивалентен "-s100k;" (было "-s20k;")

прочие улучшения:SFX/Installer: больше не сжимается UPX, поскольку антивирусы ужасно тормозили при сканировании больших SFX-архивов
АркИнфо/lt: более подробная инфа о словарях методов сжатия; Память упаковки/Память распаковки/Словарь для архивов .7z
-rr: при добавлении большой RR записи используется не больше памяти, чем задано в -lc
значительно улучшен перевод: Portuguese Standard
GUI: в текстовые поля в диалогах Add/... теперь можно включать пробелы, заключая текст опции в кавычки, например:
" %Y-%m-%d"
Date: " %Y-%m-%d"

исправления ошибок:LZMA-x64: не мог использовать больше 4 гб даже в 64-битной версии
unarc.exe/dll/sfx не могли расшифровывать метод Serpent (используемый в профилях шифрования Strong/Strongest)
GUI: При открытии диалога или изменении типа архива самопроизвольно отмечался чекбокс "Сжатие"

Я до конца не уверен, но идея такова, что стартовать надо приложение без видимой формы, точнее флаг видимости формы должен быть выключен, затем нужно свернуть последнюю, а затем уже показать. Вот примеры для винды:
http://stackoverflow.com/questions/4380575/how-to-launch-console-application-using-createprocess-with-minimized-main-window
http://stackoverflow.com/questions/7622052/creating-a-minimized-overlapped-window-win32

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

Но насколько я понял, FreeArc на GTK написан, так что надо будет через его вызовы это делать. Может в нём даже есть свой специальный, нативный способ?..


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



А ещё: не знаю, у всех ли так или это "by design" вообще, но у меня при отмене архивации, запущенной из консоли, вываливаются ошибки (на билде от 27 сентября):

1)
---------------------------
freearc
---------------------------
write: invalid argument (Bad file descriptor)
---------------------------
ОК
---------------------------

2)
---------------------------
freearc
---------------------------
CompressionLib_dbHm: interrupted
---------------------------
ОК
---------------------------

А раньше было что-то про зациклившуюся (или прерванную) нить (thread).

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

Есть задача по архивации 4-ёх баз. Более года всё работало хорошо.


Код: D:\Backup\DBIntermediate>Arc a -mx4 --logfile=BackupArc.log -w=D:\Backup\DBIntermediate -ep -ag%Y%m%d DBIntermediate_backup_.arc @DBIntermediate.lst
FreeArc 0.67 (November 11 2013) Creating archive: DBIntermediate_backup_20150301.arc using exe+delta+lzma:96mb:normal:32:mc16, $obj => delta+lzma:96mb:normal:32:mc16, $text => dict:64mb:75%+lzma:96mb:normal:32:mc16, $compressed => 4x4:tor:8mb:c3, $wav => tta:m1, $bmp => mm+lzma:96mb:normal:32:mc16
Memory for compression 320mb, decompression 128mb, cache 16mb
Compressed 4 files, 48,826,658,816 => 5,981,402,928 bytes. Ratio 12.25%
Compression time: cpu 23838.55 sec/real 14722.44 sec = 162%. Speed 3.32 mB/s
All OK

Bulat_Ziganshin

Цитата:

SFX/Installer: больше не сжимается UPX, поскольку антивирусы ужасно тормозили при сканировании больших SFX-архивов

таки сжаты UPX!

Цитата:

у меня при отмене архивации, запущенной из консоли, вываливаются ошибки (на билде от 27 сентября):

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


Цитата:

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

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


Цитата:

То есть надо поиграться с кодом.

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

дай lt успешно созданного архива. добавь -di -di+$#! и сравни вывод умпешной и неуспешной команд

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


Цитата:

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

ещё не сделано. но я поправлю, это недолго

Цитата:

SFX/Installer: больше не сжимается UPX, поскольку антивирусы ужасно тормозили при сканировании больших SFX-архивов

egor23
Таки да!

Пруф:


Видимо, чем-то отвлёкся, что не заметил. Ждём без-упыксия...

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

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

Цитата:

дай lt успешно созданного архива. добавь -di -di+$#! и сравни вывод умпешной и неуспешной команд

lt DBIntermediate_backup_20150324.arc

Код: FreeArc 0.67 (March 15 2014) listing archive: DBIntermediate_backup_20150324.arc

Archive type: FreeArc
Total bytes: 49,715,728,384
Compressed bytes: 6,139,778,739
Ratio: 12.35%

Directory blocks: 1
Directory, bytes: 256
Directory, compressed: 175
Solid blocks: 1
Avg. blocksize: 46 gb

Compression memory: 192 mb
Decompression memory: 96 mb
Dictionary: lzma:96mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 49,715,728,384 6,139,778,739 4 exe+delta+lzma:96mb:normal:16:mc8
-----------------------------------------------------------------------------
4 files, 49,715,728,384 bytes, 6,139,778,739 compressed
All OK

insorg
ты бы ещё в хекс-коде эту картинку привёл

поправлено

1) Если честно, ключик
Цитата:

background

больше ассоциируется с программой "свернутой" в трей и/или приоритете idle (и это отсутствует - кстати под спойлер +/- можно приоритет) (а трей реализовать думаю проблем не должно возникнуть хоть и в GTK)

// 2) Я то конечно знаю что диспетчером задач можно переключить и это не важная "функция", но в VirtualDub удобно поставить idle в GUI, а самому pdf/doc читать чтобы не подвисало на пол секунды иногда.

// 3) Кстати если поток 1 то можно "повесить" его жестко на одно ядро [affinity] то возможно быстродействие только улучшится (мне кажется(я в этом почти уверен(логика говорит что так по крайней мере должно быть))) если ядер/процессоров конечно больше 1 и на том же ядре ничего другого еще не "подвешено".
//По крайней мере одна из версий foobar жестко тормозила если так не сделать на XP без AMD DueCoreOptimazer

Цитата:

добавь -di -di+$#! и сравни вывод успешной и неуспешной команд

это надо добавлять в команды архивации

Bulat_Ziganshin



Добавлено:
Вай!

Да теперь всё просто летает!
Распаковалось почти мгновенно, а не висело 1-2 минуты на 98%...

Да, можно и в трей, как WinRAR, и низкий приоритет, снова как в WinRAR. Главное чтобы фокус не граббился при запуске, а просто появлялась иконка.

Bulat_Ziganshin
Понял, добавил. Сообщу результат как отработает задача. Спасибо!

Цитата:

Добавлено:
new alpha version:

наконец свежая версия


Цитата:

есть ещё удаление комментария из архива, установка комментария из файла. ещё полезно было бы добавить кнопки Load/Save для текста комментария

Цитата:

там есть пароль и keyfile шифрования, алгоритм шифрования, и наконец пароли и keyfiles дешифрования

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

Почему sfx-архивы FreeArc'a некоторые антивирусы принимают за зловредов?

Задача отработала успешно:


Код: Compressed 4 files, 49,172,566,016 => 6,146,246,240 bytes. Ratio 12.50%
Compression time: cpu 13723.78 sec/real 9259.52 sec = 148%. Speed 5.31 mB/s
All OK

insorg
ты и сам мог распаковать sfx'ы командой upx -d


Цитата:

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

давай уточню: в CUI никаких проблем с этими фичами нет. проблема в том, чтобы выработать удобный для их использования GUI. а для этого надо как раз быть "опытным пользователем этих опций"