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

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

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

Maz



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



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

Текущая английская бета-версия: 7.01 beta 1 x86 | x64
Текущая русская бета-версия:  7.01 beta 1 x86 | x64
Примечание: английская бета-версия обновляется регулярно, без изменения номера версии. подробнее...
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

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

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

Коллекционный архив версий WinRAR 1.54b - 7.00 (1995-2024): скачать (336.4 МБ) [обновлено 28.02.2024]

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

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

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

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

Всего записей: 38845 | Зарегистр. 26-02-2002 | Отправлено: 08:31 31-07-2023 | Исправлено: DimmY, 00:57 26-04-2024
EugeneRoshal

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

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

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

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

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

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

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

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



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

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

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

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



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

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

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

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

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

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

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

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



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

Всего записей: 16793 | Зарегистр. 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 будут пользовательские данные? Может, ввести дополнительный ключ сжатия?

Всего записей: 1016 | Зарегистр. 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> для потоков мне недолго. Но тогда возникнут вопросы уже про размер словаря. А увеличивать размер словаря это увеличивать расход памяти. Причем такой рост требований к памяти, вплоть до двукратного, может оказаться неожиданным для пользователя. Сейчас же фактически подчеркивается, что и метод, и словарь там самостоятельные.
 
Если это реально станет проблемой для пользователей, буду думать, что с этим делать.

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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



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

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

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

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

Читал.

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

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

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

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

Всего записей: 2266 | Зарегистр. 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

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


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru