Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc (часть 4)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156

Открыть новую тему     Написать ответ в эту тему

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Часть 1 | Часть 2 | Часть 3


Скачать последний релиз - FreeArc 0.666 от 20 мая 2010 г. Что нового: ускорение работы в 1.5-2 раза благодаря новой технологии многопоточного сжатия, распаковка архивов многих форматов используя технологии 7-zip, запуск файлов из архива, исправлены все проблемы интеграции с Explоrer (подробнее)
Текущая альфа версия: 0.67 - загрузка | список исправлений | блог


Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Планы дальнейшего развития
Что подразумевается под "интеграцией с Explorer"
Старая FreeArc wiki (включая описание формата архива)
Логотип и иконки FreeArc - обсуждение того, как облагородить внешний вид программы


Сторонние оболочки для работы с FreeArc:
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip - менеджер архивов с поддержкой большого количества форматов, для Windows и Linux


Родственные темы:
Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах
ISDone.dll - библиотека распаковки архивов в инсталяторах
REP & SREP
Пережатиe/Pекомпрессия/Oптимизация файлов для лучшего сжатия - "а как сжать ещё лучше?"
FreeArc и Unix - для альтернативно одарённых
• репозиторий FreeArc 'Next на github.com
• тема FreeArc 'Next на форуме encode.su
• раздел FreeArc на форуме krinkels.org

 
Другие архиваторы:
WinRAR
7-zip
PowerArchiver
HaoZip
BandiZip


Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 11:36 23-11-2010 | Исправлено: Release, 10:58 24-04-2023
Alex_Piggy

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Добрый день, Bulat_Ziganshin
freearc.exe при архивировании с удалением файлов, иногда не выдает ошибки (в логе пишет "архив успешно создан"), удаляет что может (могут остаться пустые папки), но не переименовывает freearc1.tmp в "имя_архива.arc".
Возможно ли сделать удаление после переименования и с каким-нибудь прогресс-баром?  
Прошу прощения за сумбурное изложение. Версия альфа от 23 ноября и от 5 февраля.

Всего записей: 1883 | Зарегистр. 07-08-2002 | Отправлено: 20:51 06-02-2012 | Исправлено: Alex_Piggy, 20:52 06-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
 
Экспериментирую с новой версией.
 
В методе -m1 при замене:
-m1 -mc:rep/rep:96m:64:c64 -mc:4x4/4x4:tor:3:2m:h128k
у меня обычно уменьшается время и улучшается сжатие, например:
 
FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.                                                                            
Compressed 1,026 files, 758,272,286 => 614,504,948 bytes. Ratio 81.0%      
Compression time: cpu 30.90 secs, real 8.75 secs. Speed 86,655 kB/s
 
FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.                                                                            
Compressed 1,026 files, 758,272,286 => 613,661,514 bytes. Ratio 80.9%      
Compression time: cpu 28.27 secs, real 8.41 secs. Speed 90,147 kB/s
 
Проверьте на своих данных.
 
Добавлено:
Вот результат для вашего же файла
http://freearc.org/HFCB.aspx
(мой компьютер примерно в 1,5 раза медленнее)
 
FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.  
Compressed 1 file, 4,244,176,896 => 1,295,281,921 bytes. Ratio 30.5%        
Compression time: cpu 104.02 secs, real 79.33 secs. Speed 53,500 kB/s
 
FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:128:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.  
Compressed 1 file, 4,244,176,896 => 1,281,669,520 bytes. Ratio 30.1%        
Compression time: cpu 100.78 secs, real 79.89 secs. Speed 53,126 kB/s
 
Здесь время примерно одинаковое.
 
Добавлено:
Извиняюсь, по ошибке rep:...128:с64.
Привожу для 64:с64
 
FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.  
Compressed 1 file, 4,244,176,896 => 1,278,343,363 bytes. Ratio 30.1%        
Compression time: cpu 101.21 secs, real 79.17 secs. Speed 53,605 kB/s

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 23:15 07-02-2012 | Исправлено: Shuld, 23:31 07-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
имеет смысл проверить на промежуточном 128:c128, по отдельности изменения в rep и tor, на большем числе файлов и исключить влияние I/O (в частности слить 1031 файл в один)

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 23:47 07-02-2012
vishyakov

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
У меня архив проходит тестирование, но при распаковке происходит ошибка.

Всё, разобрался. Оказывается, чтобы увидеть сообщение об ошибке, надо раскрыть комбобокс...

Всего записей: 29 | Зарегистр. 18-03-2009 | Отправлено: 03:22 08-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
имеет смысл проверить на промежуточном 128:c128

 
Вообще-то я проверяю все, начиная от 256:с256 и до 16:с16, включая 128:с64.
Проверять долго. (На вскидку, крайние варианты: 256:с256 и 16:с16 малоинтересны.
Вариант 128:с128 интересен, скорее всего для самых быстрых tor:3:...:h64k)
 

Цитата:
по отдельности изменения в rep и tor

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

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 18:22 08-02-2012
slech



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
1. Качаю архив и выбираю открыть http://www.snort.org/downloads/1416
2. Захожу в FA во второй архив - новое окошко открывается.
3. Выбираю директорию doc - Extract.
4. Получаю ошибку что архива нет.
 
Добавлено:
Так же есть проблема если это действие выполнить несколько раз
Архив скачивается несколько раз Firefox
snort-2.9.2.1.tar.gz
snort-2.9.2.1.tar-1.gz
snort-2.9.2.1.tar-2.gz
 
Вложеный архив в первом открывается нормально. В последующих появляется проблема.
Похоже что проблема вызвана пересечением имён и как следствие созданием уникального имени с snort-2.9.2.1.tar-1 который FA незнает как открыть и появляется окошко Windows с предложение выбрать программу для открытия неизвестного типа файла.

Всего записей: 4893 | Зарегистр. 10-11-2004 | Отправлено: 20:39 10-02-2012 | Исправлено: slech, 14:31 17-09-2013
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Всё, разобрался. Оказывается, чтобы увидеть сообщение об ошибке, надо раскрыть комбобокс...

 
а вот это ошибка. при появлении ошибок он сам должен раскрываться


это жесть. сегодня получил письмо, причём с отметкой urgent:
 

Цитата:
Здравствуйте, Булат.
Спасибо вам за добротный архиватор FreeArc.
Для многих моих задач он подходит.
 
Однако у меня есть ещё вполне практическая задача, с которой ваш архиватор НЕ справился, даже со специальными опциями, в частности –tp3.
Для меня она очень важна.
Речь идёт о распаковке записей спортивных соревнований с телевизора Sony Bravia.
 
Файлы сохраняются на внешнем жёстком диске в сжатом виде, предположительно, с помощью алгоритма LZ77.
Об этом я сделал вывод, скачав в Интернете файлы обновления ПО для этого телевизора (см. папка “crypto”).
 
Поэтому я прошу вас как специалиста в данной сфере помощи – хотя бы направьте мои усилия в правильном направлении.
 
В Приложении к этому письму есть архив с папкой “crypto”, 2 короткими записями видео в MPEG-2 , 2 ENC-файла, возможно, нужные для распаковки (они также были на внешнем диске).  

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:54 11-02-2012
snkreg

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Надо было закончить пост вот так:
"P.S. Телевизор не мой, я просто разместил объяву")
Кстати, планировал брать Sony, но если сабж не распаковывает записи спорт.соревнований - я буду вынужден вернуть с дачи старый Фотон 51ТЦ-408Д.  
А если по делу - хотел спросить. Не планируется ли интеграция последнего SREPа и детальная настройка SFX модулей?

Всего записей: 586 | Зарегистр. 18-10-2008 | Отправлено: 01:06 11-02-2012 | Исправлено: snkreg, 01:07 11-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Однако у меня есть ещё вполне практическая задача, с которой ваш архиватор НЕ справился, даже со специальными опциями

Да, это жесть...

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 13:57 11-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Rep и быстрые tor (tor:3)
Предварительные результаты

 
В новой версии архиватора FreeArc от 6.02.2012 значительно изменился rep и появились новые настройки. Выкладываю предварительные результаты тестирования этих настроек.
 
1.    Показательно изменение параметра «l» при неизменных остальных.
 
Пример 1: –mrep:1g:…:c64+xtor:3:4m:h128k, где многоточием обозначен изменяемый параметр.
Rep:1g размер Время, с    
(папка) (757 717 055) -    
512:c64 435 553 870 6.98    
256:c64 434 891 330 6.98    
128:c64 434 048 209 6.92    
64:c64 433 866 762 6.84

Видно, что изменение параметра l от 512:c64 до 64:c64, приводит к увеличению сжатия без изменения времени (разное время – похоже больше на погрешность, чем на зависимость).
Это выполняется для всех больших значений параметра c (с256..с64). Т.е. уменьшение l от «512» до значения, равного c; приводит к увеличению сжатия при одинаковом времени.
 
Пример 2: –mrep:1g:…:c16+xtor:3:4m:h128k, где многоточием обозначен изменяемый параметр.
Rep:1g Rep:1g Время, с    
(папка) (757 717 055) -    
128:c16 434 040 142 8,58    
64:c16 432 966 237 8,45    
32:c16 432 812 353 8,52    
16:c16 434 040 537 8,95

Видно, что изменение параметра l от 128:c16 до 16:c16, сначала приводит к увеличению сжатия, а затем сжатие ухудшается. Результат при 16:c16 получается хуже, чем даже 128:c16. Время практически не меняется.
Хорошо для данного примера выглядит 32:c16.
Подобным образом иногда выглядят зависимости для c32. Т.е. метод 32:c32 бывает хуже, чем 64:c32.
 
Проанализировав таким образом сжатие различных папок при различных значениях параметров (в частности, разный размер хэш-таблицы у tor, что не влияло на характер зависимости) для различных значений «c» оптимальными получаются следующие пары:
128:c128
64:c64
64:c32
32:c16
Для некоторых данных оптимальным вместо 64:c32 было 32:c32, тут можно лишь сказать, что оптимума на все случаи жизни не существует. И нужно выбирать вариант исходя из статистики. Вариант 16:c16 у меня всегда получался плохим.
 
2.    Какая пара «l» и «c» лучше для быстрых tor?
Я анализировал пары «l» и «c» для различных tor, от xtor:3:4m:h64k до xtor:6:4m:h512k:l2. Массив данных большой (более 20 значений для одной тестируемой папки). Такое большое количество значений очень неудобно анализировать с помощью таблиц, зато все очень наглядно на графике. Охватывается сразу!

Для других данных график выглядит немного по-другому. Я выбрал наиболее показательный график.
Здесь одним цветом показано семейство при разных параметрах rep, но при одном и том же tor.
Рассмотрим красный график для xtor:3:4m:h128k. Вверху, чуть слева - точка rep:1g:128:c128k. Далее в следующем порядке:
128:c128
64:c64
64:c32
32:c16
Оптимальным смотрится значение 64:c32. При 32:c16 график уходит резко вправо, т.е. время сильно увеличивается при незначительном увеличении сжатия. При 128:c128 график уходит резко вверх, т.е. время уменьшается мало, а сжатие резко ухудшается.
 
3. Какая пара rep и tor оптимальна?
Выбирать следует из следующих вариантов:
–mrep:1g:64:c32+xtor:3:4m:h64k
–mrep:1g:64:c32+xtor:3:4m:h128k
–mrep:1g:64:c32+xtor:3:4m:h256k
Если выбрать средний, второй вариант, то по сравнению с существующим сейчас методом –m1 (rep:1g:256:c256+xtor:3:4m:h256k) он покажет примерно то же время (или чуть лучше), при значительно лучшем сжатии.
 
Добавлено:
4. Попытки использовать для быстрых tor конструкции вида rep:...:96:d4m:s32:c16 показали их неоптимальность. Попытки оптимизировать привели к тем же вариантам, что описаны выше.

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 11:00 19-02-2012 | Исправлено: Shuld, 13:51 19-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Не планируется ли интеграция последнего SREPа и детальная настройка SFX модулей?

 
интеграция на уровне включения srep.exe в дистрибутив freearc и опции для его использования - уже есть. на уровне включения распаковщика srep:f в код arc/unarc/afx - возможно сделаю, но это будет временное решение как нынешний dispack. в конечном счёте планируется сделать srep внутренним методов freearc, но даже в альфе это появится лишь через несколько месяцев
 
детальная настройка SFX модулей - считаю её низкоприоритетной, поскольку есть innosetup и даже генераторы программ под него
 
Добавлено:
Shuld
1. надеюсь, теперь проверка идёт полностью в озу
2. вместо сжатия папки лучше брать один файл (объединить свои файлы вместе, учитывая порядок сортировки при -m1 и при других методах)
3. fa использует rep:96m
4. помимо использованных тобой вариантов, интерес представляют 128:c128, 64:c64 и т.д.
5. что касается оптимальности - такое ощущение, что ты скорее искал точку перегиба точных данных ты не привёл (советую делать тиблицу хотя бы под тегом more), но на глаз это выглядит так - 128:c128 процентов на 5 быстрее и жмёт на 0.2-0.5% хуже чем 64:c32. при таких условиях я выберу 128:c128
 
вообще в новой альфе не только новый rep, но и новые настройки rep для m1-m4. в быстрых методах используется l==с потому, что я счёт это более выгодным
 
ситуация вообще такая - скорость rep определяется в основном параметром C - это куски, на которые разбивается входной файл и среди них ищутся совпадения. из найденных совпадений отбрасываются те, длина которых меньше L. поэтому скорость вырастает при большом C, а при равных C большой L её даже чуть снижает - мы проверяем всё те же совпадения, затем часть из них отбрасываем, и приходится обрабатывать эти данные снова. поэтому для быстрых режимов лучше l==с - тут нет смысла разбрасываться уже найденными матчами, поскольку снижение "проходного барьера" L только улучшает общий результат
 
разные L и С имеют смысл при использовании перед lzma:max, например - нам наплевать на время и мы хотим найти все или почти все совпадения длиной от 512 байт. тогда мы разбиваем файл на куски по 128 байт и через такой частый бредень почти ни один интересующий нас матч не проскользнёт
 
для более быстрых и менее аккуратных методов сжатия (начиная с 4x4:lzma) нас интересуют совпадения меньшей длины и можно ставить хоть l32. проблема в том, что это может оказаться довольно медленно, т.е. ограничением выступает уже скорость rep. поэтому в -m1 я использую 256:c256 и т.д. неагрессивность этих настроек исходит из принципа "не навреди"
 
ps: получился небольшой rep:faq

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:28 19-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
1. Где взять последний fazip?
2. Не умею
3. Да, знаю, что rep:96m.
4-5. Штука в том, что  
метод –mrep:...:256:c256+xtor:3:4m:h256k уступит методу –mrep:...:64:c32+xtor:3:4m:h128k
и далее
–mrep:...:256:c256+xtor:3:4m:h128k уступит методу –mrep:...:64:c32+xtor:3:4m:h64k  
 
Добавлено:
Поэтому параметры типа 256:c256, 128:c128, 64:c64 не имеет смысла использовать нигде, кроме самого первого, быстрого метода!!!
 
Добавлено:
Грубо говоря, параметры 256:c256, 128:c128, 64:c64 можно использовать только с tor:3:...:h64k и нигде больше!!!

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 14:21 19-02-2012 | Исправлено: Shuld, 14:23 19-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
freearc.exe при архивировании с удалением файлов, иногда не выдает ошибки (в логе пишет "архив успешно создан"), удаляет что может (могут остаться пустые папки), но не переименовывает freearc1.tmp в "имя_архива.arc".  
Возможно ли сделать удаление после переименования и с каким-нибудь прогресс-баром?  

http://code.google.com/p/freearc/issues/detail?id=291
 
дело в том, что перенос файлов в архив рассматривается как единая операция - либо она целиком выполнена, либо нет. если не удалось удалить часть файлов - операция оказалась неудачной и тебе остаётся от неё архив просто как способ вручную исправить ошибку так как ты считаешь нужным - удалив архив или вручную удалив оставшиеся файлы или ещё как. то, что для твоих нужд удобен второй вариант, не означает что так же нужно и другим. можно это сделать на уровне опций, но я не уверен, что это настолько часто происходит
 
Добавлено:

Цитата:
–mrep:...:256:c256+xtor:3:4m:h128k уступит методу –mrep:...:64:c32+xtor:3:4m:h64k  

 
по сжатию - уступит на доли процента, по скорости - превзойдёт
 
 
Добавлено:
http://freearc.org/download/testing/fazip02.zip

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:32 19-02-2012
ruduk

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shuld

Цитата:
2. Не умею

Учитесь  Все уже давно есть, нужно было поискать по форуму:
http://freearc.org/download/testdata/dll100.7z
http://freearc.org/download/testdata/dll700.7z

Всего записей: 123 | Зарегистр. 08-02-2009 | Отправлено: 01:35 21-02-2012
Alex_Piggy

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Добрый день, Bulat_Ziganshin

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

К сожалению, после архивации в GUI уже однажды удалил freearc1.tmp, не посмотрев, что он стер все кроме пустой папки. Посчитал, что из-за ошибки прервалась именно архивация и попробовал сжать еще раз.
Проблема в том, что в GUI при ошибке удаления он выводит сообщение только в логе полном (идентичном логу консольной версии). В кратком (который подстрочный в главном окне) указывается, что все в порядке. И окно архивации тоже закрывается без всяких предупреждений.
Пример:  лог полный (options>view logfile) лог краткий
 
В консольной версии хоть "|| (echo ERROR && pause)" прицепить можно... но тогда лучше без удаления, с "&& rd /q /s".

Всего записей: 1883 | Зарегистр. 07-08-2002 | Отправлено: 20:28 22-02-2012 | Исправлено: Alex_Piggy, 20:30 22-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Alex_Piggy
ясно. спасибо, буду разбираться

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 23:46 22-02-2012
Sig666

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Вроде баг в unarc.dll: если указанный архив не найден или не является архивом, то бесконечно начинает вызываться event("error", -14, 0, "ERROR: this is not FreeArc archive or this archive is co
rrupt")

Всего записей: 134 | Зарегистр. 15-01-2008 | Отправлено: 23:48 23-02-2012
death7lord



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
не могу разобраться с командной строкой...
набрал код
Arc a -u Pak1.zip Pak.zip "media"
но в итоге у меня Pak.zip и папка media упаковываются в один Pak1.zip...
 
короче мне бы получить:
1. папку media запихнуть в уже существующий zip-архив, заменив совпадающие файлы
т.е. желательно без распаковки\запаковки архивов
2. и как в ISdone это же прописать без ком. строки?

Всего записей: 40 | Зарегистр. 09-12-2010 | Отправлено: 02:26 24-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
1.  
copy pak.zip pak1.zip
arc -tzip pak1.zip media
2. "isdone" в шапке

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 02:37 24-02-2012
VicF1

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Здравствуйте.
Подскажите пожалуйста, почему когда я создаю архив через диалог, в графе сжатие прописываю например "precomp+delta+srep:a1+lzma:d260m:a1:mfbt4:fb273:lc8", то создание архива не завершается, время только увеличивается. Даже файлы в пару КБ стопарятся на определенном проценте (процент зависит от размера файла).
Дело явно в precomp...
Спасибо за разъяснения.

Всего записей: 92 | Зарегистр. 25-12-2007 | Отправлено: 10:32 25-02-2012
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc (часть 4)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru