Эта опция могла бы стать выходом. Например обновлялись бы только те куски, в которых были изменения (удаление/добавление/изменения), причём небольшой размер куска позволял бы обработать ситуация, когда из источника удаляется большая часть файлов и заменяется новой, а на приёмнике нет места для пересоздания всего архива.
» FreeArc (часть 4)
Эта опция могла бы стать выходом. Например обновлялись бы только те куски, в которых были изменения (удаление/добавление/изменения), причём небольшой размер куска позволял бы обработать ситуация, когда из источника удаляется большая часть файлов и заменяется новой, а на приёмнике нет места для пересоздания всего архива.
Цитата:
мне кажется что в процессе архивации сотые интересны только конченым гикам.
А мне кажется что гики тоже люди. А для не совсем конченных гиков, можно и десятые доли выводить.
Фриарк, ведь, для таких маньяков/гиков и разрабатывался, да и кто, если не ты, Булат, что-то сделает для гиков?
Тем более что:
Цитата:
а зачем нормальному пользователю использовать freearc, а не rar/zip?
пожалуйста -

Bulat_Ziganshin
Цитата:
v8
красивое решение.
дописывать новые данные в конец существующего файла из всех известных мне архиваторов умеет только zpaq, плюс в нём дедупликация и поколения файлов, так что рекомендую для бекапов
или классически - один архив с базовой версией, плюс дополнительные для инкрементов
Цитата:
Ну да, на логе в UTF-8 показало что текста мало:
я попробовал и на логах, и худтекстах в utf8 - детектятся как текст. могу предположить что у тебя много строчек одинаковой длины
Цитата:
Burat нашел один баг.
спасибо, записал
Цитата:
--volume=SIZE несовместима с --sync ?
-v не работает с arc-архивами, а 7-zip если и обновляет многотомники, то создаёт новые копии
terenty79
пока идёт работа над переводами
ещё одна вариация с отступлением от "классических канонов" - (v9)
..............Files .... Compressed ........ Bytes ...... Time
Processed ....... 8 ..... 6,229,876 ... 16,188,368 ... 0:00:02
Total .......... 35 .. ~ 51,893,133 .. 134,844,601 . ~ 0:00:17
.............................. | ...... | .. | ............ |
.............................. +- 38 % -+ .. +- 7,970 kB/s -+
................................ Ratio .......... Speed
не совсем логично получается, что Compressed и Bytes переставлены местами
зато Ratio и Speed очень наглядны, кмк
более логичный, но и более громоздкий вариант - (v10)
..............Files ........ Bytes .... Compressed ...... Time
Processed ....... 8 ... 16,188,368 ..... 6,229,876 ... 0:00:02
Total .......... 35 .. 134,844,601 .. ~ 51,893,133 . ~ 0:00:17
.............................. | ............ | ........... |
..................... Ratio .. +---- 38 % ----+ ........... |
..................... Speed .. +--------- 7,970 kB/s -------+
Цитата:
пока идёт работа над переводами
В примере меню нужно пару строк (19 и 62) обновить

-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
подретушировал твои варианты и добавил их как v11 и v12 на http://freearc.org/download/testing/progress/


Добавлено:
вариация v8, выводящая Speed справа:
v13 - http://freearc.org/download/testing/progress/FreeArc13.exe :

v9

v10

Цитата:
я попробовал и на логах, и худтекстах в utf8 - детектятся как текст. могу предположить что у тебя много строчек одинаковой длины
Да, есть такое, бывает 5-10 строк подряд одинаковой длины.
Цитата:
или классически - один архив с базовой версией, плюс дополнительные для инкрементов
С удовольствием бы, но ситуацию "удалил 300гб и записал 300гб новых данных" это не обработает, так как место на источнике и приёмнике примерно одинаково, и эти удалённые 300гб не очистяться.
..............Files......Time............Bytes.... .Compressed..
Processed ........8.....0:00:02.......16,188,368.....6,229,876..
Total ...........35...~ 0:00:17......134,844,601..~ 51,893,133..
..........................|..............|....|... ....|........
..........................+- 7,970 kB/s -+....+- 38 % -+........
...............................Speed .......... Ratio...........
или на офсайте: http://nsis.sourceforge.net/FreeArc_plug-in
muzf
попробуй - наверно получится

это v11 с Ratio и Speed в обратном порядке. я думаю что мне надо центрировать Speed/Ratio в последней строке, отказавшись от какого-либо выравнивания с числами над разделителем. и возможно добавить ETA (время завершения операции) в самом конце - это очень удобно для длительных операций
Добавлено на http://freearc.org/download/testing/progress/
ppmd,4x4,cls,external + 4 алгоритма шифрования
сделали зачем-то алгоритм, которому нужно в 100 - 1000 раз больше CPU для повышения сжатия на 3-8 % по сравнению с zlib
Compress data more densely with Zopfli - Google Developers Blog
http://googledevelopers.blogspot.nl/2013/02/compress-data-more-densely-with-zopfli.html
при том, что в 7-zip сто лет в обед есть оптимизированный тот же самый Deflate, который даёт такой же выигрыш по сжатию гораздо меньшими усилиями:
"For ZIP and GZIP formats, 7-Zip provides a compression ratio that is 2-10 % better than the ratio provided by PKZip and WinZip"
рассказать им что ли?..
v14 как-то больше нравится, всё просто и понятно
Proceeded: 58%
Files: 2823/5447
Bytes: 24984984/52046849
Compressed: 4984984/2046849
Ratio: 72%
Time: 01:02:03/20:22:24
На первом месте - процент обработанного, далее - количество файлов (сделано/всё) и аналогично байты общие и обработанные, после этого логичнее всего показывать процент сжатия, и в конце - время по схеме [прошло/общее] или [прошло/осталось].
Как вариант, можно время разделить:
Обработано: 58%
Файлы: 2823/5447
Всего байт: 24984984/2046849
Сжатых байт: 4984984/2046849
Степень сжатия: 72%
Прошло: 01:02:03
Осталось: 20:22:24
Или даже так...
Proceeded: 58% Time: 01:02:03/20:22:24
Files: 2823/5447 Ratio: 72%
Bytes: 24984984/52046849 Compressed: 4984984/2046849
з.ы.
Числа взяты рандомные, просто для наглядности что как должно выглядеть.
да я вообще не понимаю, почему гугл пользуется устаревшим deflate вместо прогрессивного freearc

Цитата:
да я вообще не понимаю, почему гугл пользуется устаревшим deflate вместо прогрессивного freearc
это, конечно, да - FreeArc рулит!

но, к сожалению, не везде его (сейчас) получится использовать
например, PNG основан на Deflate или, скажем, сжатие HTTP трафика
Цитата:
Another proposal for idea from v9+v10
как-то не интуитивно получается - "знаменатели" слева от "числителей"
(Speed = Bytes / Time, Ratio = Compressed / Bytes)
GUI: "FileName": open: permission denied (Permission denied).
Uharc.exe: ERROR: can't open file "FileName" | с атрибутом "Только чтение" - распаковывается нормально.
Arc.exe:"FileName": open: permission denied (Permission denied).
2. Если начать распаковывать архив, нажать "отмена", то можно получить следующиe ошибки:
2.1: Распаковываем частично (через GUI папка/файл(ы)): ArcExtract.hs:152:56-126-Non-exhaustive patterns in lambda. Повторное нажатие "отмена": User error.
2.2: Распаковываем весь архив, через меню: wclose: invalid argument (Bad file description).
2.3: Распаковываем весь архив через GUI: User error - два раза. Повторное нажатие "отмена": User error -> CompressionLib_dbHm: interrupted.
После пунктов 2.1 и 2.3, FreeArc закрывается.
Было бы неплохо если распаковку можно было прерывать без ошибок

Proceeded: 58% Files: 2823/5447
Compressed: 4984984/2046849 Ratio: 72%
Speed: 5204kb/s Time: 01:02:03/20:22:24

C:\>timer exdupe.exe -o -x0 -t12 -v5 i:\4g nul
COMPRESSED 4,531,060,447 bytes in 1 file(s) into 3,675,346,418 bytes
Kernel Time = 1.388 = 00:00:01.388 = 17%
User Time = 48.953 = 00:00:48.953 = 604%
Process Time = 50.341 = 00:00:50.341 = 621%
Global Time = 8.096 = 00:00:08.096 = 100%
C:\>srep64g.exe -m0 -l4k -nomd5 -mmap -s22. I:\4g nul
100%: 4,531,060,447 -> 3,603,337,912: 79.53%. Cpu 597 mb/s (7.238 sec), real 591 mb/s (7.315 sec) = 99%
Kernel Time = 0.936 = 00:00:00.936 = 12%
User Time = 7.238 = 00:00:07.238 = 98%
Process Time = 8.174 = 00:00:08.174 = 111%
Global Time = 7.347 = 00:00:07.347 = 100%
Добавлено:
Edison007007
1. посмотрю
2. да, там большие проблемы с обработкой ошибок. к сожалению, надо основательно код переписать чтобы их решить. планируется в следующей версии
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275
Предыдущая тема: Punto Switcher (часть 3)
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.