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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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

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

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 | Исправлено: Nikolai2004, 21:23 03-02-2021
Skif_off

Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Дополнительная инфа:
скопировал все из \include в \bin - ошибка при запуске precomp.exe:

Код:
Сигнатура проблемы:
  Имя события проблемы:    APPCRASH
  Имя приложения:    precomp.exe
  Версия приложения:    0.0.0.0
  Отметка времени приложения:    4d0fc462
  Имя модуля с ошибкой:    packJPG_DLL.dll
  Версия модуля с ошибкой:    0.2.1.0
  Отметка времени модуля с ошибкой:    4e900bc9
  Код исключения:    c0000005
  Смещение исключения:    00001d55

Жму Закрыть прогамму, в окне распаковки жму Отмена и получаю ошибку

Код:
ArcExtract.hs:152:56-126: Non-exhaustive patterns in lambda

Если предварительно закрыть основное окно FreeArc, то последней ошибки не будет то FreeArc все равно останется висеть в памяти, но тихо.
В Mulitarc роняет ТС с той же жалобой на packJPG_DLL.dll.
 
Хорошо, что с такими архивами дел не имею

Всего записей: 6222 | Зарегистр. 28-01-2008 | Отправлено: 23:04 07-04-2014 | Исправлено: Skif_off, 23:07 07-04-2014
Highpass

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

Цитата:
сейчас переделываю FA чтобы данные паковались с precomp 0.4.3. вроде единственное изменение в нём по сранению с 0.4.2 - то что вместо опции -c- надо использовать -cn? как вообще эта версия - не стала менее надёжной чем прежняя?

 
Изменение синтаксиса - это лишь малая часть отличий версии 0.4.3 от 0.4.2.
Версия 043 скомпилена статически и представляет теперь один exe файл, так что меньше размер и нет проблем с возможными конфликтами из-за файлов packjpg_dll.dll и zlib1.dll (хотя для некоторых целей это не гуд).
Движок PackJPG обновлен с 2.4wip4 до 2.5a и как следствие меньше глюков при включеной обработке JPEG. Пофиксен баг с GIF файлами, когда например на vm.dll найденые GIF файлы раздувались в temp файлы размером под 4 Гб.
Разные фиксы и улучшения, типа возможности нескольким копиям Precomp работать на одном файле, сохранении корректного имени файла в заголовке (раньше всё хранилось в lower case) и др и пр.
Но самый вкусный момент это скорость.
Fallout - Textures.bsa + Fallout - Textures2.bsa (Fallout NV)
RAMDisk (ImDisk -awe)
 

Код:
0.4.2 -intense -c-           727 sec.
0.4.3 -intense -cn                    581 sec.   <- 20% быстрее

 
Но отвечая на вопрос: версия не стала менее надежной.

Всего записей: 56 | Зарегистр. 23-06-2009 | Отправлено: 07:28 16-04-2014
hammerxp1

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Расшифруйте пожалуйста, сколько реальной памяти понадобится для распаковки при таких параметрах:
1.rep:256mb+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128
2.rep:256mb+lzma:64mb:h64m:normal:bt4:128

Всего записей: 10 | Зарегистр. 22-09-2010 | Отправлено: 14:28 16-04-2014
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
hammerxp1
256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно
 
Highpass
спасибо!

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 15:09 16-04-2014
hammerxp1

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

Цитата:
256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?
Или 256+132 это сколько требуется памяти на поток? Потому что если выставить одноядерный процессор то всё работает.
Без параметра 4x4 всё отлично, но с моим количеством обрабатываемых данных (около 40гб) не хватает скорости, а 4x4 дает ускорение при распаковке минимум в 2 раза.
Пока что перешёл на эксперименты с rep:256+tor:15, разница в размере получаемого архива не такая значительная, зато скорость распаковки почти в 2 раза выше. Кстати tor:16 при упаковке тоже не хватает памяти.

Всего записей: 10 | Зарегистр. 22-09-2010 | Отправлено: 13:58 18-04-2014
UbiSergei

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shud поднял тему прогресс-бара, хочу высказаться.
 
Не очень понимаю надобность двух баров. Функция бара -- показывать какой процент работы выполнен, с его помощью можно составить прогноз, когда работа будет закончена. Если я правильно понял, верхний бар показывает, какой процент файла обработан. Но для чего это? После обработки одного файла архиватор сразу же приступает к обработке другого. Архиватор пакует файлы не друг за другом, а выборочно, по кучкам. Невозможно прервать процесс, и получить рабочий архив с определенным файлами.
 
Верхний бар имеет смысл при копировании файлов, при этом процессе ты можешь передумать о своих планах и остановить процесс, при этом сохраняя выволненную работу.
 
Другие предложения:
1) Мне очень не нравятся пустые места между параметрами и значениями. (Time-много-пустого-места-0:12).
2) Больная часть исходных данных, по моему мнению не нужна. Количество файлов смело можно выкидывать, с этой информацией ничего не поделаешь (не остановится же пользователь посередине архива, достигнув магического числа). Текущий размер во время обработки выкидываем по той же причине. Также не вижу, зачем нужен размер информации (исходный и обработанный), роль заменяется процентом.  
3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!
4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час. Вместо 'of' можно использовать слэш. Идея из uTorrent.
5) Заголовок: я бы поменял вертикальныю черту на слэш. Но это на усмотрение, у меня какая-то нелюбовь к этому знаку. Еще можно поставить разделитель между процентом и временем.
 
   
 
Вместо жирности можно использовать различие размеров шрифта, сейчас это модно, и смотрится неплохо.
 
 
Добавлено:
По поводу набора команд в меню Explorer. Некоторы предложения для строк.
 
1) Выкиньте 'the selected files' -- файловое меню не показывается при отсутствии выделенных файлов
2) 'using Freearc' -> '(Freearc)', или 'with Freearc', 'via Freearc' (сэкономит целый симбол в меню); еще лучше совсем Freearc выкинуть, как в меню 7-Zip. Мы же все равно рассчитываем, что Freearc в скором будущем станет единственный архиватором на машинах пользователей
3)  '... via dialog', 'Extract, Test with Freearc' -> Compress, Open, Extract, Test archive (tnx 7-Zip).
4) 'Extract to a folder', 'Extract here'.
 
 
Добавлено:
В голову пришла еще одна замечательнаяы идея. Вчера смотрел видео на ted.com, понравилось как у них время отображается по краям на прогресс-баре. Идею с легкостью можно перенести и сюда.
 
Прогресс = Обработано данных/ Всего данных
Всего времени = Прошло времени * (Всего данных/Обработано данных)
Прошло времени / Всего времени = Обработано данных / Всего данных
 
Превьюшка с метро-дизайном
   
 
Добавлено:
И в дробных числах лучше использовать точку, я не запятую.

Всего записей: 7 | Зарегистр. 22-08-2012 | Отправлено: 13:29 25-04-2014 | Исправлено: UbiSergei, 15:05 25-04-2014
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
UbiSergei
Первый бар (в моем предложении) - "процент" выполненой работы (в целом, а не по файлам!)
Второй бар - размер "архива", т.е. показатель "эффективности" работы!

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 15:14 26-04-2014 | Исправлено: Shuld, 15:15 26-04-2014
UbiSergei

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shuld
Значит второй бар просто показывает коэфициент сжатия,  понятно. Как обидно это было бы не говорить, но надобности в нем тоже не вижу: на протяжении процесса жизни ратио колеблется слабо. Бары для вещей у которых есть начало и конец, ратио же почти постоянен.
 
Это же идея из винрара? Похоже, что авторы изначально не продумали концепцию.

Всего записей: 7 | Зарегистр. 22-08-2012 | Отправлено: 18:26 27-04-2014
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
UbiSergei
Вы постоянно путаете.
В WinRAR как раз по-файлово.

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 21:53 27-04-2014
UbiSergei

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shuld
Спасибо за поправку. Давно им не пользовался.

Всего записей: 7 | Зарегистр. 22-08-2012 | Отправлено: 17:26 04-05-2014
hammerxp1

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Пока занимался своей разработкой, случайно получился эксперимент.
Имеем 3 папки, в каждой папке набор файлов с системного диска разных ос.
(dll,exe,mui,inf и тд. и тп.)
 
1. файлов 57671, размер  8,86 Гб.
2. файлов 79349, размер 13,57 Гб.
3. файлов 75584, размер 12,21 Гб.
 
После сжатия всех папок (rep:256mb+tor:15, сортировка -dsgercpn) получаем размер архива 2,43 Гб. (2 613 137 764)
 
Удаляем в каждой папке дублированные файлы. Получаем:
1. файлов 37124, размер 4,96 Гб.
2. файлов 49469, размер 7,62 Гб.
3. файлов 49895, размер 7,19 Гб.
 
После сжатия: (rep:256mb+tor:15, сортировка -dsgercpn) получаем размер архива 2,42 Гб. (2 605 761 577)
 
Вывод: rep прекрасно справляется с дупликацией файлов.

Всего записей: 10 | Зарегистр. 22-09-2010 | Отправлено: 08:01 07-05-2014 | Исправлено: hammerxp1, 08:10 07-05-2014
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
hammerxp1
Вывод: в данном случае rep со словарём 256 мб прекрасно справляется с дупликацией файлов  поскольку rep:256m по определению не может найти повторы на расстоянии больше 256 мб, очевидно что в данном случае -dsgercpn успешно переупорядочила файлы так, чтобы повторы находились на меньшем расстоянии. но не всегда это возможно, для таких случаев и нужен srep, который находит повторы на всём объёме данных
 
Добавлено:

Цитата:
Верхний прогресс-бар и все, что выше - относится к исходным данным  
Нижний прогресс-бар и ниже - к архиву.  

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:42 07-05-2014 | Исправлено: Bulat_Ziganshin, 14:56 07-05-2014
Bulat_Ziganshin

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

Цитата:
Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?  

там много всего намешано. -mt по умолчанию выставляется в кол-во ядер/потоков cpu. в 4x4 можно явно укзаать числдо потоков упаковки с помощью :t, по умолчанию оно приравнивается к опции -mt. после того как параметр же таким образом задан, arc проверяет хватит ли памяти для упаковки и если нет - обрезает его. при этом даже если вы явно задали :t при сжатии - он вырезается из записываемого в архив определения (смотрится командой arcindo/lt) исходя из предположения что этот параметр вы задали для сжатия, а при распаковке могут быть какие угодно (и неизвестные заранее) условия
 
при распаковке происходит примерно то же самое, только :t у нас понятно никакого нету - ему неоткуда взяться. но это делает arc. как работает unarc и как он определяет размер ОЗУ в виртуалке - надо посомтреть, помнится мне что там что-то проще сделано поскольку это отдельный алгоритм на C++, а основной в arc на хаскеле. опцию -mt в unarc наверно надо добавить для таких горемык
 
если tor:15 близко к lzma сжимает - его и используйте. добавьте ещё :c3 - это ускорит распаковку
 

Цитата:
Кстати tor:16 при упаковке тоже не хватает памяти.

с гигом озу? ну да, ему 1.5 гига нужно (с дефолтным 128 мб словарём), как и lzma:max. вообще с 40 гб файлом надо в сторону srep смотреть, вроде есть cls-srep.dll для его распаковки на лету

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:08 08-05-2014 | Исправлено: Bulat_Ziganshin, 00:14 08-05-2014
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
hammerxp1
если интересуетесь сжатием, вот подопытный
NDP452-KB2901951-x86-x64-DevPack.exe 328МБ
http://www.microsoft.com/en-us/download/details.aspx?id=42637
 
содержимое можно сжать сильнее, как минимум до 150МБ

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 12:53 08-05-2014 | Исправлено: egor23, 13:02 08-05-2014
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
опцию -mt в unarc/dll/sfx приделал

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:11 08-05-2014
Bulat_Ziganshin

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

Цитата:
2) Большая часть исходных данных, по моему мнению не нужна. Количество файлов смело можно выкидывать, с этой информацией ничего не поделаешь (не остановится же пользователь посередине архива, достигнув магического числа). Текущий размер во время обработки выкидываем по той же причине. Также не вижу, зачем нужен размер информации (исходный и обработанный), роль заменяется процентом.  
 
3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!  
 
4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час.  

дело в том что нынешний "широкий" индикатор прогресса разработан для гиков, для тех кому важна каждая деталь выполняемой операции. поэтому там размеры до байтов, время в секундах и прочее. я думаю, что надо делать альтернативный индикатор прогресса с минимумом деталей, твой дизайн под него мне кажется подходящим, вместе с упрощением самой информации (размер в МБ, время в часах-минутах и т.д.). т.е. исходить из того что большинству людей интересно. имхо, это ratio, speed, исходный размер данных, (предсказываемое) общее время работы

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 16:37 09-05-2014 | Исправлено: Bulat_Ziganshin, 16:37 09-05-2014
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Может быть более прогрессивный вариант?
Каждый индикатор может быть размещен где хочется пользователю (мышкой), правой кнопкой мыши - количество знаков после запятой (или показывать или нет секунды и т.п.)
Все это запоминается в настройках (скинах?).
Я лично тогда сделаю, как мне будет удобно.
 
Добавлено:

Цитата:
и что в нём за проценты - степень сжатия?

Верхний прогресс-бар - обработанные исходные данные/ все исходные данные
 
Нижний прогресс-бар - текущий размер архива/ все исходные данные.
Когда сжатие закончится - это будет процент сжатия.

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 15:07 10-05-2014
aslav



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Как десктопный архиватор сабж более не развивается автором?
Я не для флейма интересуюсь, и говорить - "возьми и скачай, пользуйся - работает же".
 
4 года новой паблик версии нет. роадмэп завис на 2012 году.
 
Отсюда вопрос - для паблика вскоре планируется что-то или сабж можно рассматривать как поле для экспериментов энтузиастов борьбы за минимизацию интересующимися и личное хобби автора?

Всего записей: 279 | Зарегистр. 02-03-2006 | Отправлено: 14:53 11-05-2014
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
aslav
Постоянно выходят новые версии.
И в этом году уже были.
Вы в топике ссылку
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=0&limit=1&m=1#1
смотрели?
Или здесь:
http://freearc.org/Download-Alpha.aspx
Я бы версией 0,666 пользоваться не советовал - в ней есть ошибки.  
Почему автор не обновляет релиз?
Не знаю. Ищет идеала...

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 20:18 14-05-2014
hammerxp1

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

Цитата:
опцию -mt в unarc/dll/sfx приделал

Просто отлично! но, как работает можно поподробнее,и где скачать, потестить.

Цитата:
с гигом озу? ну да, ему 1.5 гига нужно

Упаковываю я на мощной машине, это распаковывать пытаюсь на слабых конфигурациях.
 
Идея про дубликаты файлов:
Под свои потребности пока что реализовал так: написал махонькую программку,перед упаковкой она ищет дубликаты файлов, создает txt файлик в корне упаковываемой папки, в нём чётные (отсчёт с нуля) строки это относительные пути к файлу оригиналу, не чётные это пути к файлу дубликату. Потом пробегается по нечётных строкам и удаляет все файлы.
Далее упаковываем, а когда распаковываем архив запускается программа опять, она берет файл с чётной строки и копирует его в путь нечётной.
Примерно так выглядит txt:
\test\file1.dll         -чётн
\test\1\file1.dll      -нечётн
\test\file1.dll         -чётн
\test\2\otherfile1.dll -нечёт (имя может быть другим, а содержание тоже)
\test\file2.exe
\test\2\file2.exe.bak
 
Кстати я реализовал ещё круче вместо файлов дубликатов (при условии что система на диске ntfs) создаются хардлинки (жёсткие ссылки) что после распаковки ещё и место на диске экономит. Но тут много подводных камней и не всегда применимо.
Надеюсь более менее понятно написал, я в "весёлом настроении"

Всего записей: 10 | Зарегистр. 22-09-2010 | Отправлено: 14:39 20-05-2014 | Исправлено: hammerxp1, 15:29 20-05-2014
Открыть новую тему     Написать ответ в эту тему

Страницы: 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

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


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru

Рейтинг.ru