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

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

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

Maz



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



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

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

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

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

Коллекция всех ранее выходивших версий WinRAR 1.54b - 6.00 (1995-2020): скачать (265 МБ) [обновлено 10.01.2021]

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

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

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

В теме активно отвечает на вопросы автор архиватора Евгений Рошал! Ситуация уникальная, прошу пользоваться.

Всего записей: 37563 | Зарегистр. 26-02-2002 | Отправлено: 19:30 27-08-2020 | Исправлено: DimmY, 17:48 23-12-2021
insorg



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Цитата:
делать перед распаковкой дополнительный проход на сканирование всех заголовков файлов
Зачем дополнительный? При открытии архива вполне логично получать полный его листинг, тем более как без этого узнать содержимое архива...
Хотя, если я ошибаюсь, то можно и только перед распаковкой, чтобы не тратить время каждый раз.
Цитата:
затраты не только памяти, но и времени
WinRAR и так достаточно долго (по сравнению с 7z или zip с таким же составом архива) открывает архивы. Особенно не-solid. На медленных хардах и сетевых дисках заметно. Потому я не вижу существенной потери в том, чтобы дополнительно за этот же проход чтения составить порядок следования файлов. Как минимум столь долгое чтение будет использовано с большей пользой.
Цитата:
Возможно 7-zip так и поступает, я не в курсе.
Исходники не копал (квалификация не та), но по опыту использования (как в повседневке, так и архивами-милионниками) очень похоже на то.
Цитата:
потом выполнять отдельный проход для распаковки только этих пар
Если это проще реализовать, то согласен и на то. Главное - чтоб работало. Хотя, кмк, более рационально - получать листинг и вытаскивать за один проход.

Всего записей: 2320 | Зарегистр. 04-11-2010 | Отправлено: 22:23 02-11-2021 | Исправлено: insorg, 22:26 02-11-2021
EugeneRoshal

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

Цитата:
Зачем дополнительный? При открытии архива вполне логично получать полный его листинг, тем более как без этого узнать содержимое архива...  

Для распаковки обычного rar архива без ссылок нам не нужен его полный листинг. Мы идем от одного заголовка файла к другому и обрабатываем файлы по мере обнаружения. Но такой подход не работает, если мы встретили 2.txt, который нам надо распаковать, и он ссылается на 1.txt, который мы уже пропустили раньше. Тут нужно или предварительное сканирование заголовков для обнаружения таких пар перед распаковкой, или дополнительный проход для распаковки только таких файлов.
 
Так как мы не знаем, встретятся ли нам в архиве ссылки, предварительное чтение всех заголовков придется выполнять для любых архивов, не только со ссылками. Возможно, 7-Zip так и поступает, что позволяет ему распаковывать отдельные ссылки и оптимизировать распаковку отдельных файлов внутри solid блоков. Но это замедлит распаковку любых RAR архивов на время чтения всех заголовков. Замедлит не особо значительно, но тут надо учитывать малую распространенность архивов со ссылками и с множеством solid блоков по сравнению со всеми остальными.

Цитата:
WinRAR и так достаточно долго (по сравнению с 7z или zip с таким же составом архива) открывает архивы. Особенно не-solid. На медленных хардах и сетевых дисках заметно. Потому я не вижу существенной потери в том, чтобы дополнительно за этот же проход чтения составить порядок следования файлов.

Если вы про чтение заголовков, так наоборот для архивов типа rar без гарантированной central directory, хранящей все заголовки в конце архива, дополнительный проход обойдется дороже, так как потребует больше перемещений внутри архива. Но у central directory есть своя цена. Если она дублирует локальные заголовки, она увеличивает размер архива. Если она является единственным источником информации о файлах, она делает архив более уязвимым к повреждениям, так как информация о файлах не распределена по архиву, а хранится в одном месте. Поэтому в RAR5 это реализовано опционально в варианте дублирования заголовков как "Quick open information" .

Всего записей: 1606 | Зарегистр. 29-04-2013 | Отправлено: 22:49 02-11-2021
uShell

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

Цитата:
в современной консольной версии для *nix систем

Строго говоря, это p7zip, а не 7-Zip. А, точно, появилась официальная версия.
 

Цитата:
При открытии архива вполне логично получать полный его листинг

А ведь верно, WinRAR (GUI) это должен всё равно делать. Тогда логично будет закэшировать этот список и перед вызовом распаковки/удаления сверяться с перечнем ссылок. Разве что надо следить, чтобы архив внезапно не поменялся.

Всего записей: 541 | Зарегистр. 12-06-2019 | Отправлено: 22:51 02-11-2021 | Исправлено: uShell, 23:06 02-11-2021
los

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

Цитата:
Строго говоря, это p7zip, а не 7-Zip.  

строго говоря это 7-Zip, а не p7zip.
_https://sourceforge.net/p/sevenzip/discussion/45797/thread/ba29828ce0/

Всего записей: 5420 | Зарегистр. 08-09-2001 | Отправлено: 22:55 02-11-2021
insorg



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Цитата:
Так как мы не знаем, встретятся ли нам в архиве ссылки, предварительное чтение всех заголовков придется выполнять для любых архивов, не только со ссылками
Определять по тому, что сжатый "размер" файла равен нулю. Вполне себе критерий для того, чтобы определить, нужно ли чтение заголовков.
Цитата:
дополнительный проход обойдется дороже, так как потребует больше перемещений внутри архива
Но при этом второй проход будет уже читаться из кеша. Ровно как и второе открытие (только что открывавшегося медленно) архива происходит почти моментально.
Цитата:
для архивов типа rar без гарантированной central directory
Ах вот оно что... Ясно тогда в чём дело.
 
uShell
Цитата:
WinRAR (GUI) это должен всё равно делать
Ну, собственно да, речь и про гуи, и про unRAR.dll, которая используется вместе с тотал коммандером и им подобными.
Цитата:
Тогда логично будет закэшировать этот список и перед вызовом распаковки/удаления сверяться с перечнем ссылок.
Это вполне разумно.  
EugeneRoshal
Осуществимо?
Цитата:
Разве что надо следить, чтобы архив внезапно не поменялся.
А с чего б ему поменяться, если при открытии сделать его занятым.

Всего записей: 2320 | Зарегистр. 04-11-2010 | Отправлено: 22:59 02-11-2021 | Исправлено: insorg, 23:06 02-11-2021
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
uShell
Цитата:
WinRAR (GUI) это должен всё равно делать
Не должен, если запущен с параметрами командной строки (или из контекстного меню вызван).

Всего записей: 10178 | Зарегистр. 11-03-2002 | Отправлено: 23:05 02-11-2021
insorg



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Даже если guiшка используется для распаковки из комстроки, всё равно более логично при наличии  в архиве файлов-ссылок (с определёнными свойствами, их и отловить) делать листинг перед распаковкой, а не идти "в лоб".
 
Ну, или ещё одно (третье уже) решение, это хранить какой-то маркерный бит в теле rar файла, который отвечает за присутствие файлов-ссылок и за необходимость получать полный листинг перед распаковкой. Тем более, что где-нибудь в начале/конце архива явно должен был остаться хотя бы один свободный неиспользуемый бит.
Хотя, это уже явные костыли и имеет ряд недостатков, в том числе правку уже существующих архивов с таким содержимым.

Всего записей: 2320 | Зарегистр. 04-11-2010 | Отправлено: 23:08 02-11-2021 | Исправлено: insorg, 23:13 02-11-2021
EugeneRoshal

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

Цитата:
Ну, собственно да, речь и про гуи


Цитата:
Осуществимо?  

Это не поможет в случае командной строки или контекстного меню. Там нет ранее прочитанного списка, который можно закэшировать.
 
Про флаг в заголовке архива для устранения последствий для прочих архивов я тоже думал. Как вариант, да, но для архивов, созданных существующими версиями, это не даст результата.

Всего записей: 1606 | Зарегистр. 29-04-2013 | Отправлено: 23:19 02-11-2021
insorg



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Но в существующих rar5 архивах есть свободный бит? Их же можно "пропатчить"? По тому же принципу как работает "заблокировать от изменений", например. Не перепаковывая всё.
В крайнем случае, до "лучших времён" это уже будет хоть что-то.
 
Ну, либо рубить капитально:
1. добавить в следующей версии какой-нибудь комстроковый параметр на принудительный листинг перед распаковкой
2. добавить в гуи версию (отключаемое) чтение листинга при открытии архива (всё-равно содержимое архива ему же надо показать, так пусть листит всё)
Так, по крайней мере, ничего "патчить" не надо будет...

Всего записей: 2320 | Зарегистр. 04-11-2010 | Отправлено: 23:23 02-11-2021 | Исправлено: insorg, 23:26 02-11-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
los, Pasha_ZZZ - замечания учёл, спасибо.

Цитата:
сжатый "размер" файла равен нулю

Чтобы узнать сжатый размер, как раз и надо читать заголовок, т.к. команда на извлечение обычно содержит только имена. То есть всё равно требуется чтение архива в два прохода: 1) заголовки, разрешение ссылок; 2) извлечение нужных файлов.
 

Цитата:
дополнительный проход обойдется дороже


Цитата:
второй проход будет уже читаться из кеша

Вот тут затрудняюсь оценить - надо проверять. Думаю, если архив большой, а время случайного доступа к диску велико (с убитым лазером, например), то проблема будет. Зато двухпроходная схема даст более точную оценку прогресса распаковки, а также экономию времени для частично непрерывных архивов: если при создании был задан ключ -sn или -se, то можно будет начинать распаковку с начала группы.

Всего записей: 541 | Зарегистр. 12-06-2019 | Отправлено: 23:24 02-11-2021
insorg



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

Цитата:
частично непрерывных архивов
А так можно было что ли? Как? Зачем?
М-да... Я думал, что жестоко хотеть листинг перед распаковкой, но если даже такие архивы кто-то делает, то я вижу её просто обязательной. Так и очередь можно сформировать, и более грамотно место выделить на целевом месте (меньше фрагментация!), и как бонус возможно даже скорость распаковки не терять в особо тяжёлых случаях.

Всего записей: 2320 | Зарегистр. 04-11-2010 | Отправлено: 23:28 02-11-2021 | Исправлено: insorg, 23:29 02-11-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Да, кстати, если среди списка на извлечение нет масок, то первый проход можно прервать, как только найдены все файлы. Если ссылка не может идти в архиве перед целью, то этого будет достаточно.
 
Добавлено:
EugeneRoshal
Предлагаю двухпроходную схему сделать опциональной (по ключу), а заодно реализовать "двухпроходное" внесение изменений в GUI: отмеченные файлы сохраняются, а перед выполнением операции выводится их список с кнопками Commit/Discard. Особенно удобно было бы выбирать файлы для удаления в разных каталогах архива, что сейчас доступно только из консоли.

Всего записей: 541 | Зарегистр. 12-06-2019 | Отправлено: 23:29 02-11-2021
EugeneRoshal

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

Цитата:
А так можно было что ли? Как? Зачем?

Теоретически формат позволяет, реально почти не используется. Ключ -s<N>. Сейчас единственная его польза это несколько большая устойчивость такого архива к повреждениям по сравнению с чистым solid.
 
Область применения таких архивов ограничена с двух сторон чистыми solid (максимальное сжатие) и не solid (скорость индивидуального доступа и устойчивость к ошибкам) и вряд ли велика.

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

Я вижу возможный выигрыш только в скорости распаковки отдельных файлов из solid групп.
 
uShell
Насколько я помню, нечто подобное RAR сейчас делает при обычной распаковке. Если все указанные имена уже обработаны и не содержат wildcards, распаковку можно завершить досрочно, не сканируя остаток архива.
 
Добавлено:
uShell

Цитата:
Предлагаю двухпроходную схему сделать опциональной (по ключу)

Это если при реализации такой схемы окажется, что задержка неприемлемо высока.
 
Пока я не уверен, что люди достаточно часто пользуются ссылками в архиве, поэтому и не занимался распаковкой отдельных ссылок. Это довольно объемная задача, а по почте эту тему поднимают редко.  
 
Если бы я реально взялся это реализовывать, сначала бы проверил сколько времени отнимет дополнительный проход чтения заголовков, если его применить ко всем архивам. Может оно и не так страшно. Потом рассмотрел бы вариант с флагом в заголовке или с дополнительным проходом распаковки только для ссылок вместо дополнительного прохода чтения заголовков. Про ключ скорее всего пользователь вспомнит только после неудачной попытки распаковки такого архива, да и то, только если упомянуть такой ключ прямо в сообщении об ошибке.
 
Добавлено:
insorg

Цитата:
Но в существующих rar5 архивах есть свободный бит?

Да, место для дополнительных флагов в заголовке rar5 архива есть.

Всего записей: 1606 | Зарегистр. 29-04-2013 | Отправлено: 23:52 02-11-2021 | Исправлено: EugeneRoshal, 00:24 03-11-2021
insorg



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Как сказать. У меня довольно много таких архивов, где есть дубликаты больше размера словаря. Даже больше 4 гигов файлы дубликаты. В основном это ресурсы к играм, их версии и моды, а ещё прочие личные архивы сборок. Либо разные версии софта типа браузеров или подборок портативок с настройками. Сразу из архива взял нужный вариант, и не надо мучиться с переборкой каждый раз.
Просто не все знают, что так можно, а для меня антидубликат при упаковке - реальная киллер фича. Особенно офигенно, что на эти дубликаты не надо тратить словарь и время при упаковке.
Да что там, по сравнению с 7z это (кроме RR) реально весомый повод вернуться к WinRAR на постоянку.
 
Так что неистово топлю за возможность удобно распаковывать дубликаты без вытаскивания лишнего. Желательно чтоб это работало сразу в связке Total commander + unRar.dll...
Хотя в качестве первого решения готов потестить и обычный guiшный вариант.

Всего записей: 2320 | Зарегистр. 04-11-2010 | Отправлено: 01:20 03-11-2021 | Исправлено: insorg, 01:25 03-11-2021
Peter15

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Если файл заархивирован в многотомный архив (rar или sfx) с паролем, и пароль знаю только я, гарантируется ли неизменность запакованного файла после распаковки, если пароль принимается нормально? Т. е. если какой-то том из общего набора изменить, то я это замечу по ошибке распаковки при вводе исходного пароля?

Всего записей: 340 | Зарегистр. 02-01-2019 | Отправлено: 02:10 03-11-2021 | Исправлено: Peter15, 02:10 03-11-2021
Inoz2000



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

Всего записей: 3548 | Зарегистр. 23-04-2009 | Отправлено: 02:15 03-11-2021
Peter15

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

Цитата:
Что мешает проверить самому?
 

Хочется проверить для файла размером несколько Гб, а чем "портить" тома, нужно ещё найти.

Всего записей: 340 | Зарегистр. 02-01-2019 | Отправлено: 02:45 03-11-2021
uShell

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

Цитата:
чем "портить" тома, нужно ещё найти

Любой шестнадцатиричный редактор. Но обычное затирание нулями, скорее всего, будет обнаружено. Попробуйте подменить конец исходного файла, сохранив исходный и сжатый размеры: последовательности нулей уменьшают сжатый размер, а случайных данных - увеличивают. Если получится - перед Вами пример атаки с подменой последнего тома. Один, но не последний подменить вряд ли получится.
 

Цитата:
гарантируется ли неизменность запакованного файла

Теперь можно ответить на этот вопрос: если целостность запакованного файла контролируется CRC32, то подмена в принципе возможна (про подбор CRC читайте в интернете), но для успешной атаки нужно иметь исходный файл. Если при упаковке указать использование BLAKE2sp, то описанный выше сценарий не прокатит и степень защиты будет примерно такой же высокой, как при использовании ЭЦП.

Всего записей: 541 | Зарегистр. 12-06-2019 | Отправлено: 08:37 03-11-2021
persicum

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Peter15
Если один том изменился, то сообщение об ошибке будет дважды. Во-первых, что том поврежден, а во вторых, что файл поврежден. По крайней мере, если файл длинный.
 
Но я понял из комментариев, к чему вы клоните. Вы хотите использовать известный только вам пароль как валидизатор или цифровую подпись того, что архив не изменялся.
 
Сначала нужно ответить на этот вопрос для обычного однотомного архива, там пароль что-то гарантирует или нет? Я даже не знаю, пароль на файл вызывает его шифрование по AES?
 
Добавлено:
uShell

Цитата:
Если при упаковке указать использование BLAKE2sp, то описанный выше сценарий не прокатит и степень защиты будет примерно такой же высокой, как при использовании ЭЦП.

А если пропатчить само поле с blake2sp?

Всего записей: 456 | Зарегистр. 27-06-2007 | Отправлено: 09:10 03-11-2021
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Peter15
uShell
persicum
В принципе, если архив не солид и выключено шифрование заголовков - можно удалить пошифрованный файл и на его место добавить другой файл, без пароля.
Беспарольные файлы всегда распаковываются без ошибки, даже если указан пароль.

Всего записей: 10178 | Зарегистр. 11-03-2002 | Отправлено: 09:21 03-11-2021
Открыть новую тему     Написать ответ в эту тему

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

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


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru

Рейтинг.ru