» FreeArc: бесплатный open-source архиватор

Bulat_Ziganshin

Цитата:

дык надо же использовать arc x http://... arc.exe ! вообще, можно и на 7zip перейти, хотя мне казалось, что с .arc, который можно распаковать прямо с сети, даже удобней

привычка - скачать, а потом распаковать.

Цитата:

Допустим если добавить папку C:\GtkRun\2.8\etc\fonts\
то файлы в архиве должны сохранятся только с родительской папкой, а не полным путем, например:

fonts\fonts.conf

опции -dp/-ap существуют как раз для этого. если представить себе FAR, в котором с одной стороны открыт архив archive, в котором текущий каталог arcdir, а с другой стороны - диск, в котором текущий каталог - diskdir, то копирование из архива на диск должно осуществляться командой

arc x archive -ap=arcdir -dp=diskdir

а обратно:

arc a archive -ap=arcdir -dp=diskdir

вот и вся премудрость. правда, есть проблема с копированием целых каталогов, сейчас насколько я помню её нужно делать, записывая имя каталога дважды "dir dir/" или может "dir dir/*":

arc a archive -ap=arcdir -dp=diskdir dir dir/
arc x archive -ap=arcdir -dp=diskdir dir dir/*

в общем, разберёшься надеюсь сам


Цитата:

хотя это не выход

есть предложения как сделать лучше?

Добавлено:
P.S. а традиционно (в других архиваторах) это делается путём перехода в папку C:\GtkRun\2.8\etc и запуском архиватора оттуда. просто у меня вместо того, чтобы менять текущий каталог программы, можно указать -dp - это сработает аналогично

Добавлено:

Цитата:

А собирался еще в старой теме

ну это я вообще собирался. в таких-то планах у нас недостатка нет )

Цитата:

Если будете делать реализацию похожую на WinRK предусматрите её отключение

дык! разве у меня что-либо когда-либо не отключалось?

Цитата:

Если есть посекторный CRC в архиве:
1. Сделайте распаковку архива с пропуском битых солид-блоков.
2. Сделайте распаковку битых солид-блоков до битого участка.

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

Цитата:

Да, на личном опыте уже убедился в проигрывании 7-зипу при неких условиях. Но ведь в 7-зипе нет определения по типу файлов, так, только по расширению. И в фриарке сортировка посложней будет. Может просто сделать ключ отключающий "умную" сортировку? Или может даже в дефаулте это сделать?

"быть ни в чём не хуже 7-zip" - это не наши методы. надо идти вперёд, а не окапываться. поэтому по умолчанию это делать бессмысленно, а вручную - лехко: -m4b/4b, к примеру, это -m4 c чисто бинарным сжатием (и отключением exe-препроцессинга на obj-файлах). ещё ближе к 7z можно сделать так: -m4b/$exe=exe+4b

Bulat_Ziganshin

Цитата:

есть предложения как сделать лучше?

или как говорили - "по-умолчанию", должно быть
или как предложил SCINER - опция -ep4

ещё один пример:

>Arc040-pre4.exe a a -r
Compressed 13.823 files, 137.075.894 => 30.403.624 bytes. Ratio 22.1%
Compression time 124.26 secs, speed 1.103 kb/s. Total 191.37 secs

>Arc.exe a a -r
Compressed 13.823 files, 137.075.894 => 30.197.709 bytes. Ratio 22.0%
Compression time 117.59 secs, speed 1.166 kb/s. Total 189.63 secs

>Arc.exe a a -r -ms
Compressed 13.823 files, 137.075.894 => 30.371.592 bytes. Ratio 22.1%
Compression time 78.80 secs, speed 1.739 kb/s. Total 148.22 secs

здесь выигрыш во времени получен главным образом за счёт отказа от сжатия заведомо несжимаемых файлов. даже без -ms выигрыш в степени сжатия всего 0.7%

Цитата:

думаю, что это нужно будет сделать как часть реализации общей идеи сегментации. а на данный момент я собрался сделать автоопределение типа файлов - ибо кол-во пользователей, не способных/не имеющих времени настроить arc.groups уже становится великовато. вон и на китайском форуме уже пишут, что fa нередко сжимает хуже 7zip - подозреваю что это связано именно с неправильным определением типа файла

ИМХО, такое определение надо реализовывать как "алгоритмы сжатия" со многими выходными потоками: текст - в один поток, исполняемый код - в другой(а сюда ещё bcj2...), и однотипные потоки данных объединять в солид-блоки.

GUI - фтопку(тем более, я видел где-то, кто-то обещал этим заняться). Даёшь сжатие маленьких файлов и функционал(многотомность,и надёжное хранение)!

Registered User

Цитата:

ИМХО, такое определение надо реализовывать как "алгоритмы сжатия" со многими выходными потоками: текст - в один поток, исполняемый код - в другой(а сюда ещё bcj2...), и однотипные потоки данных объединять в солид-блоки.

Это так и делается.


Цитата:

GUI - фтопку(тем более, я видел где-то, кто-то обещал этим заняться). Даёшь сжатие маленьких файлов и функционал(многотомность,и надёжное хранение)!

Не будет GUI - не будет широкого распространения.

Пардон, я забыл - обсуждалось или нет:
нельзя ли сделать шифрование архива с использованием системы двойных ключей (GnuPG/PGP) - открытым ключом шифруется, закрытым расшифровывается (или наоборот )?
Или (и) цифровую подпись (сертификат и т.п.) - проверка целостности архива. Можно ломать цифровую подпись при расшифровке (как бы "одноразовая разрушаемая упаковка")...

Цитата:

Это так и делается.

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

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


Цитата:

Даёшь сжатие маленьких файлов

не понял


Цитата:

нельзя ли сделать шифрование архива с использованием системы двойных ключей (GnuPG/PGP) - открытым ключом шифруется, закрытым расшифровывается (или наоборот )?
Или (и) цифровую подпись

в далёком-далёком будущем обязательно сделаю, в т.ч. симметричную цифровую подпись (когда подписывающий и пароверяюший пользуются одним ключом) - как в winzip/peazip


Цитата:

Можно ломать цифровую подпись при расшифровке (как бы "одноразовая разрушаемая упаковка")...

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

Bulat_Ziganshin

Цитата:

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

ага, тогда в этом аспекте речь велась на предыдущей странице.

Цитата:

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

с минусами этого варианта, на первое время, ужыться можно.
...
Один вариант без предварительного анализа на ходу.
Другой вариант с предварительным анализом.
и оба варианта нужны.

Добавлено:

Цитата:

что память потребуется одновременно для всех алгоритмов

а возможно делать так?
чтобы применять последовательно алгоритмы "на лету"(уже не совсем на лету)
сегментированные данные или сбрасывать в temp-файл или держать в памяти (если место есть).
естественно для тех алгоритмов для которых памяти не хватает.

Цитата:

а возможно делать так?
чтобы применять последовательно алгоритмы "на лету"(уже не совсем на лету)
сегментированные данные или сбрасывать в temp-файл или держать в памяти (если место есть).
естественно для тех алгоритмов для которых памяти не хватает.

интересная идея. если сравнить с предварительным сегментированием, то получится так:

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

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

второе выглядит в моих глазах немного привлекательней

Цитата:

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

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

Цитата:

. в общем, это можно использовать в быстрых режимах

Цитата:

Даёшь сжатие маленьких файлов
не понял

FreeArc наиболее эффективен на больших наборах данных, из-за rep. На маленьких наборах, когда rep бесполезен,фриарк плох.

Bulat_Ziganshin

Цитата:

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

а при "на лету" почти тоже самое с распаковкой, или я что-то из виду упустил?

Цитата:

Вместо --original, в команде восстановления архива можно использовать опцию --save-bad-ranges=FILENAME. Она записывает в заданный файл список частей архива, которые нужно выкачать заново. Вы можете использовать этот список для выкачки данных утилитой вроде curl и затем пропатчить ими архив.

Не хватает ручного восстановления, т.е. когда нету сетевого доступа к оригиналу, участвуют два пользователя:
1. "Битый" пользователь - отсылает не битому данные: или список битых(если был посекторный CRC), или отсылает посекторный CRC.
2. "Не битый" пользователь - получив эти данные делает патч и отсылает "битому".
3. "Битый" пользователь - получив патч, восстанавливает архив.

Цитата:

Вы можете использовать этот список для выкачки данных утилитой вроде curl и затем пропатчить ими архив.

Хотелось бы чтобы все делал сам FreeArc.

Цитата:

Хотелось бы чтобы все делал сам FreeArc.

напиши сам такую утилиту, чего ж тутт сложного?

Bulat_Ziganshin

Цитата:

напиши сам такую утилиту, чего ж тутт сложного?

Утилиты-то есть.
Вот потому-что реализация не сложная и прошу.
Т.е. если реализация чего-то началась нужно её довести для всех случаев жизни.

качайте http://www.haskell.org/bz/arc.arc !

Ого Arc-gui.exe, здОрово
Bulat_Ziganshin
Приложению не удалось запуститься, поскольку zlib1.dll не был найден

Добавлено:
добавил какой-то zlib1 версии 1.2.2.0
Всё равно не запускается.

Цитата:

Приложеньицу не удалось запуститься

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

Bulat_Ziganshin
2.2 мега без GUI -> 13.1 мега с ним. Не буду говорить за всех, но для пользователей консольной версии посредством FAR или TC овчинка выделки точно не стоит.

Хотя пусть будет. Кому нравится, будут пользоваться. В конце концов это основа для будущей полноценной GUI-версии, а размер - плата за портабельность под linux.

Цитата:

TC

насчёт TC ты думаю ошибаешься. да и пользователи FAR наверно предпочтут графический индикатор прогресса. останутся в основном "автоматизаторы". учти, что графическую версию легче сделать более навороченной. пожелания принимаются у кого нет собственных мыслей, могут голосовать по моему списку:


Код: GUI
окно сообщения об ошибке; подокно варнингов
вылет при неправильном пароле
current file, use processing time for speed/estimated time
учитывать, что cbytes может отставать от b (индейская хитрость!)
tips for labels that explore their data
объём озу, используемый текущим алгоритмом
добавлять в UI_Read/num=0 имя читаемого файла (или завести отдельную очередь),
что позволит точнее отображать processed files/current file в CUI и GUI
обновлять раз в 0.5 секунды всё, кроме progressBarSetFraction
checkbox "Close on exit"; "Remaining time", "Estimated endtime"
поддержка -m5p (external compressors)

Цитата:

качайте http://www.haskell.org/bz/arc.arc !

только не говори что для того что бы распоковать необходимо что то скачать

Добавлено:
не запускается.
в Readme написано что нужно компилить. я так понимаю уже откомпиленая выложена. как отследить почему не запускается ?

Bulat_Ziganshin
Насчет TC - наверно ты прав. А вот если бы пользователи FAR "предпочитали графический", то они бы уже давно перестали быть пользователями FAR'a Впрочем, тоже не показатель, ибо с каждым годом их число уменьшается - по сути с 2000 года FAR остановился в развитии.


Цитата:

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

Ну что ж. Если говорить всерьез о графической версии, то в результате (в идеале) хотелось бы увидеть полноценный продукт вроде WinZip, PowerArchiver, WinRAR или чего-то подобного. Отдельные окошки с индикаторами прогресса, статистикой, некоторыми опциями (то, что в твоем списке) - они хороши для ранних версий.

подскажите как извлечь файлы в определённый каталог ?
arc e arc.arc d:\test ?

slech

Цитата:

только не говори что для того что бы распоковать необходимо что то скачать

Все DLL'ки, лежащие в архиве, необходимы для работы GUI-версии. Нужно качать все.

Цитата:

подскажите как извлечь файлы в определённый каталог ?

arc x arc.arc -dp=d:\test

c остальным как я понимаю ты уже разобрался?


Цитата:

хотелось бы увидеть полноценный продукт

это отдельный вопрос. сейчас я спрашиваю, что доделать в этом окогечке прежде чем двигаться дальше. чтобы не получилорсь так, что программа состоит сплошь из недоделанных частей если нынешний функционал устраивает - пиши ЗАЧОТ


Цитата:

только не говори что для того что бы распоковать необходимо что то скачать

зачем скачивать, можно распаковать прям с инета LOL

arc x http://www.haskell.org/bz/arc.arc arc.exe

Добавлено:

Цитата:

се DLL'ки, лежащие в архиве, необходимы для работы GUI-версии. Нужно качать все.

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

Bulat_Ziganshin

Цитата:

если нынешний функционал устраивает - пиши ЗАЧОТ

Пишу: ЗАЧОТ

Я был бы больше рад, если бы сначала вместо зачатков GUI добавились must have фичи полнофункционального архиватора (multi-volume, независимые тома, sfx, полноценный RR). Просто для того, чтобы еще до появления графической версии FreeARC мог полноценно заменить на моем компьютере RAR и 7zip.

Но если нужно обязательно что-то выбрать из твоего списка, то, пожалуй, можно начать с:

- current file, use processing time for speed/estimated time
- окно сообщения об ошибке; подокно варнингов
- вылет при неправильном пароле - только не "вылет", а диалог с сообщением об ошибке. каждый раз перезапускать архиватор при неправильном пароле - не дело

Добавлено:

Цитата:

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

Отож Видишь, как люди быстро к хорошему привыкают

Bulat_Ziganshin

Цитата:

arc x arc.arc -dp=d:\test

с распоковкой разобрался. как же всё же быть с GUI - не запускается.
win2k3 en sp1

slech

Цитата:

с распоковкой разобрался. как же всё же быть с GUI - не запускается

Если ты думаешь запустить его как WinZip, то и не запустится

Пока что весь GUI - это индикатор прогресса в процессе работы. Набери что-нть вроде
arc-gui a test c:\windows и увидишь, что есть на данный момент.

Benchmark
а я то сразу и не догнал.

Цитата:

полноценный RR

что именно?


Цитата:

вылет при неправильном пароле - только не "вылет", а диалог с сообщением об ошибке.

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


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

Цитата:

так что сначала сделаю gui

Вот это мне тоже нравится!