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

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

Модерирует : 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 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180

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

Maz



Дед Мазай
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
По вопросам лечения (кряки, патчи и т.д.), а также разблокировки архивов обращаемся в «Варезник».
Отдельная тема по сборкам WinRAR
Предыдущие части темы: 0 | 1 | 2 | 3 | 4



 
Официальный русский сайт: win-rar.com
Официальный e-mail разработчика WinRAR (писать по-русски): dev@rarlab.com
 
Стабильная английская версия: 7.13
Стабильная русская версия: 7.13


Последняя 32-разрядная версия (7.01): английская | русская


 
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

Скачать ранее вышедшие версии можно с официального FTP
Список версий совместимых с различными ОС

Версия 3.62 (ru) с подарочным ключом (респект камраду elmorte)

Коллекция всех ранее выходивших 16- и 32-бит версий WinRAR 1.54b - 7.01 (1995-2024): скачать (342 МБ) [обновлено 12.05.2024]

вместо F.A.Q. || альтернативные архиваторы

Почему при русском разработчике задерживается русская версия, хотя на языке XXX она уже появилась? Не захламляйте тему подобными вопросами.

Кому не нравится новая тема оформления - скачайте с официального сайта rarlab.com (из раздела Themes) и установите себе WinRAR Classic theme by Francesco Indrio
Стандартная (48x36). Маленькие кнопки (24x24)

В теме активно отвечает на вопросы автор архиватора Евгений Рошал! Ситуация уникальная, прошу пользоваться. :)
 
Таблицы для наглядности с соотношением размера словаря к потребляемой ОЗУ:
с ключом mcx | без ключа mcx

Всего записей: 39598 | Зарегистр. 26-02-2002 | Отправлено: 08:31 31-07-2023 | Исправлено: Komandor, 10:46 02-08-2025
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
lucking
Записи с данными каталогов RAR хранит в конце архива, чтобы устанавливать время и права доступа каталогов после распаковки всех файлов. Иначе при создании очередного файла ранее установленное время модификации родительского каталога изменилось бы на текущее время. А ранее установленные права доступа каталога могли бы помешать создавать в нем файлы.

Цитата:
Может есть в настройках возможность прописывать запись служебной информации по архивируемым папкам в каждый том?

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

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 21:23 16-04-2024
lucking

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

Цитата:
Такой опции нет. Если важно время модификации каталогов, нужно распаковывать до последнего тома включительно.

 
Тут вопрос больше не в том, что это важно, а в том, что данная информация является частью исходных архивируемых данных. И если из промежуточного тома можно вытащить файлы в "первозданном" виде, то отсутствие такой возможности для каталогов выглядит нелогичной.
 
Получается, если по тем или иным причинам будет поврежден последний том, вся информация по дате/времени создания/изменения каталогов для всего архива будут утеряны? Хорошо, понятно)

Всего записей: 36 | Зарегистр. 15-07-2005 | Отправлено: 21:52 16-04-2024
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
lucking
Против повреждения можно сделать рекавери запись. Но в целом, логично же, что при повреждении незащищённого архива что-то в нём теряется безвозвратно. Без архива аналогично было бы. Что утеряно - того уже нет.

Всего записей: 19718 | Зарегистр. 04-11-2010 | Отправлено: 21:55 16-04-2024
nWxh

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Иногда, встречающаяся ситуация: периодический бекап Firefox расположен, например, на разделе "F". Создается его архив, который будет сохранен на разделе, например, "E". Применяемые параметры, по умолчанию:  
1. Создать непрерывный архив.  
2. Добавить данные для восстановления.  
3. Протестировать файлы после архивации.  
4. Заблокировать архив.  
Пусть редко, но архив может создаваться пару раз в день (и даже, больше). И в этом случае, поскольку архив с идентичным именем уже существует, появляется сообщение, что заблокированный архив нельзя изменить.  
Было бы удобным, если бы, наряду с этим сообщением, было и предложение заменить его. Ведь именно это и происходит, когда архив создается, тут же, и лишь затем (вырезать-вставить) переносится в нужное место, где уже есть архив с тем же именем.

Всего записей: 274 | Зарегистр. 04-04-2022 | Отправлено: 22:28 16-04-2024
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
nWxh
А не проще ли добавлять к концу архива метку даты+времени, чем натыкаться на неуникальные имена?

Всего записей: 19718 | Зарегистр. 04-11-2010 | Отправлено: 22:32 16-04-2024
nWxh

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
insorg
Все можно. И труды микроскопические. Но все же было бы приятнее видеть не только сообщение о невозможности изменения заблокированного архива, но и предложение о его замене (раз уж он идентичный).  
А так, Вы правы, любое неудобство можно обойти.

Всего записей: 274 | Зарегистр. 04-04-2022 | Отправлено: 22:41 16-04-2024
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
nWxh
У меня есть некоторые сомнения относительно такой функции.
 
По идее блокируются архивы с ценными данными, которые мы хотим защитить от случайной модификации. Мне кажется, это не совсем стыкуется с предложением удалить такой архив в начале упаковки. Получается, что мы с заблокированным архивом обращаемся даже менее бережно, чем с незаблокированным, для которого такое сообщение выводиться не будет.  
 
Возможно, тут правильнее оставить пользователю возможность самому разобраться с таким архивом, а не упрощать его удаление.
 
insorg

Цитата:
А не проще ли добавлять к концу архива метку даты+времени

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

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 00:10 17-04-2024
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
nWxh
Об идентичности архивов до начала операции никак не узнать. А, вот параметр -ag может пригодиться.  
Если я правильно помню (сам пользуюсь консольной версией rar.exe, а гуй очень редко), то в гуи версии вот оно же:
   
 
Добавлено:
EugeneRoshal
Цитата:
еще можно указать -agN
Да-да, я именно об этой штуке и имел ввиду. Там же и время, и циферки можно. Когда-то очень активно эту цацку использовал, было удобно.

Всего записей: 19718 | Зарегистр. 04-11-2010 | Отправлено: 00:22 17-04-2024
uShell

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

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

Не скачивая один из томов, Вы теряете часть информации (в том числе и о том, какие ещё есть файлы в архиве). Разве не логично? Кстати, формат архива не накладывает ограничений на место хранения каталогов: то, что они в конце - это особенности поведения текущих версий WinRAR.
 
EugeneRoshal
Кстати, некоторые архиваторы умеют распаковывать только каталоги. WinRAR, как я понял, так не умеет - верно? Да, такое требуется нечасто, но всё же было бы интересно.
Ну и вопрос вдогонку: а как поведёт себя WinRAR, если у файла есть NTFS-поток, который попадает в другой том? На уровне архива поток - отдельная сущность, но в интерфейсе он не отображается. Интересно, что будет показывать GUI, если информации о "родительском" файле в томе с потоком не окажется.
 
P.S. WinRAR продолжает игнорировать ключ -m<n> применительно к служебным данным. Да, их объём обычно невелик (но тогда почему -m3, а не -m0), но что если в потоках NTFS будут пользовательские данные? Может, ввести дополнительный ключ сжатия?

Всего записей: 1137 | Зарегистр. 12-06-2019 | Отправлено: 11:42 17-04-2024
EugeneRoshal

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

Цитата:
Кстати, некоторые архиваторы умеют распаковывать только каталоги. WinRAR, как я понял, так не умеет - верно?

Ключ -e+d. В GUI его можно указать в "Additional switches" в диалоге распаковки.

Цитата:
Ну и вопрос вдогонку: а как поведёт себя WinRAR, если у файла есть NTFS-поток, который попадает в другой том?

Проверил, делит поток между томами и распаковывает успешно. Если открыть том только с потоком в GUI, показывает пустой список файлов. В командной строке можно посмотреть на реальное содержимое такого тома с помощью "rar vta arcname.partN.rar".

Цитата:
P.S. WinRAR продолжает игнорировать ключ -m<n> применительно к служебным данным.

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

Цитата:
Да, их объём обычно невелик (но тогда почему -m3, а не -m0)

Между -m0 и -m3 разница даже на небольших объемах может быть в разы. Между -m3 и -m5 на нескольких кб хорошо если будет разница в десяток байтов.

Цитата:
но что если в потоках NTFS будут пользовательские данные?

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

Цитата:
Может, ввести дополнительный ключ сжатия?

Пока я со сколько-нибудь массовым использованием потоков NTFS для хранения больших объемов не встречался. Как правило, там какие-нибудь метаданные в пределах нескольких кб. Если люди реально начнут зачем-то в в потоках хранить большие объемы, тогда можно будет думать или про опцию, или про использование -m<n> и -md<n>.
 
Добавить использование -m<n> для потоков мне недолго. Но тогда возникнут вопросы уже про размер словаря. А увеличивать размер словаря это увеличивать расход памяти. Причем такой рост требований к памяти, вплоть до двукратного, может оказаться неожиданным для пользователя. Сейчас же фактически подчеркивается, что и метод, и словарь там самостоятельные.
 
Если это реально станет проблемой для пользователей, буду думать, что с этим делать.

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 17:09 17-04-2024
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Логика мне понятна, но хотелось бы изложить некоторые соображения.
 

Цитата:
Там еще и размер словаря ставится минимальный. Сейчас там приоритет на сжатие с минимальными требованиями к памяти, чтобы ненароком не удвоить расход памяти.

Согласен, но почему тогда не сжимать NTFS-потоки в том же контексте, что и обычные файлы (для непрерывных архивов - внутри того же solid-потока)? Памяти тогда будет потребляться столько же. По отдельности их распаковать можно только если специально постараться, поэтому пользователи GUI разницы не увидят.
 

Цитата:
Между -m0 и -m3 разница даже на небольших объемах может быть в разы.

Да, но не всегда в пользу -m3 При сжатии метаданных WinRAR почему-то не применяет алгоритм отката на -m0, если данные не удалось сжать - а сжимаемые потоки мне пока вообще не попадались. С другой стороны, Quick Open Вы решили не сжимать, тогда как в некоторых архивах она будет занимать больше места, чем любой другой служебный поток. Для сравнения: 7-Zip свой каталог всегда сжимает "нормальным" методом, а малоизвестный FreeArc позволяет настроить сжатие, причём имеет дополнительные ключи как раз для каталога.

Всего записей: 1137 | Зарегистр. 12-06-2019 | Отправлено: 18:59 17-04-2024
insorg



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

Цитата:
Добавить использование -m<n> для потоков мне недолго. Но тогда возникнут вопросы уже про размер словаря. А увеличивать размер словаря это увеличивать расход памяти. Причем такой рост требований к памяти, вплоть до двукратного, может оказаться неожиданным для пользователя. Сейчас же фактически подчеркивается, что и метод, и словарь там самостоятельные.  

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

Цитата:
 Согласен, но почему тогда не сжимать NTFS-потоки в том же контексте, что и обычные файлы (для непрерывных архивов - внутри того же solid-потока)? Памяти тогда будет потребляться столько же. По отдельности их распаковать можно только если специально постараться, поэтому пользователи GUI разницы не увидят.  

Вот, да, и я об этом.

Всего записей: 19718 | Зарегистр. 04-11-2010 | Отправлено: 19:52 17-04-2024
EugeneRoshal

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

Цитата:
Согласен, но почему тогда не сжимать NTFS-потоки в том же контексте, что и обычные файлы (для непрерывных архивов - внутри того же solid-потока)?

Если мы подмешиваем в solid поток чужеродные данные, то результат в плане сжатия не совсем очевиден. С одной стороны, возможный выигрыш в сжатии служебных данных, с другой - возможный проигрыш в сжатии основного потока. Например, если вставлять NTFS ACL после каждого файла в solid потоке с массой маленьких однотипных .txt, на сжатии самих .txt это скажется не лучшим образом.
 
Для максимального сжатия тут желательны два независимых потока, для основных и служебных данных. Но с типичными нынешними объемами служебных данных выигрыш в сжатии вряд ли оправдает усложнение кода.
 
В любом случае, без потери совместимости это не переделать.

Цитата:
С другой стороны, Quick Open Вы решили не сжимать, тогда как в некоторых архивах она будет занимать больше места, чем любой другой служебный поток.

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

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 20:06 17-04-2024
insorg



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

Цитата:
Если мы подмешиваем в solid поток чужеродные данные

Не в средине его, а после всех нормальных файлов. В хвосте блока.  
 
Добавлено:

Цитата:
В любом случае, без потери совместимости это не переделать.  

Тогда пусть уже остаётся как есть. А то потом опять беги ищи обновы для ОС, на которую уже давно основной массе наплевать.

Всего записей: 19718 | Зарегистр. 04-11-2010 | Отправлено: 20:20 17-04-2024
EugeneRoshal

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

Цитата:
Не в средине его, а после всех нормальных файлов. В хвосте блока.

В .rar архиве служебные данные файла хранятся сразу после основных данных файла. Значит, и обрабатывать их надо сразу после основных. Оно так логичнее, а с учетом дискового кэша, вероятно, и быстрее, чем сначала работать с основными данными всех файлов, а потом возвращаться к каждому файлу и читать или писать его вспомогательные данные.

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 22:11 17-04-2024
insorg



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Ясно. Тогда разве что в пределах совместимости с чтением предыдущими версиями winrar помечтать о том, чтобы для потоков можно было тоже задавать степень сжатия хотя бы минимально и прочие плюшки.

Всего записей: 19718 | Зарегистр. 04-11-2010 | Отправлено: 22:16 17-04-2024
uShell

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

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

Предлагаю всё-таки рассмотреть возможность использования существующего кода, откатывающего сжатие на -m0 при превышении размера исходного файла. Тем более что в подавляющем большинстве случаев (когда размер потока невелик) исходные данные целиком находятся в памяти и задача сводится к if (CompressedSize > Size) {Header->Method=0; SetFilePointer(); WriteFile(Header); WriteFile(buf)}.

Всего записей: 1137 | Зарегистр. 12-06-2019 | Отправлено: 22:43 17-04-2024
EugeneRoshal

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

Цитата:
чтобы для потоков можно было тоже задавать степень сжатия хотя бы минимально и прочие плюшки.

А что реально может храниться во вспомогательных данных в таком объеме, чтобы это имело смысл? Я реально в архивах видел NTFS ACL и Mark Of the Web. И то, и то - в пределах пары сотен байтов.

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 22:52 17-04-2024
lelik007



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Евгений, про форматы то. Я тут с ZStandard познакомился, более, чем бы хотел. Вы уже наверное про это читали, но может, потом и нам такое нужное? Только от этого у него скорость такая, не вижу от чего больше.
https://en.wikipedia.org/wiki/Asymmetric_numeral_systems

Всего записей: 3377 | Зарегистр. 13-10-2006 | Отправлено: 23:49 17-04-2024
EugeneRoshal

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

Цитата:
Вы уже наверное про это читали

Читал.

Цитата:
Только от этого у него скорость такая

Я с ANS не экспериментировал, но, насколько я понимаю, оно вряд ли сильно быстрее кодов Хаффмана. У ANS в общем случае выше степень сжатия.

Цитата:
но может, потом и нам такое нужное

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

Всего записей: 2605 | Зарегистр. 29-04-2013 | Отправлено: 00:21 18-04-2024
Открыть новую тему     Написать ответ в эту тему

Страницы: 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 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180

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


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru