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

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

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

Maz (27-08-2020 19:31): WinRAR (часть 4)  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199

   

gyra

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



Официальный русский сайт: win-rar.ru
Официальный e-mail разработчика WinRAR (писать на русском): dev@rarlab.com
 
Финальная английская версия: 5.91 x86 | x64 (29.06.2020)
Финальная русская версия:  5.91 x86 | x64 (29.06.2020)
 
Список изменений на английском языке
(на родном – смотрите файл WhatsNew.txt в дистрибутиве на вашем языке)
Скачать RAR для macOS, FreeBSD, Linux, Android можно здесь.

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

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

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

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

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

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

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

Всего записей: 7932 | Зарегистр. 18-02-2006 | Отправлено: 12:00 14-12-2016 | Исправлено: Domin0, 13:37 26-08-2020
EugeneRoshal

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

Цитата:
Для долгосрочного хранения всегда добавляю -rr3%

У меня 3% для бэкапов на внешний hdd, а на USB флешки в последнее время я использую RAR5 с -rr20%

Цитата:
Иногда очень помогало.

Не помните на каком носителе данных? Просто любопытно.

Всего записей: 2239 | Зарегистр. 29-04-2013 | Отправлено: 13:40 16-01-2018
Domin0



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

Цитата:
Не помните на каком носителе данных? Просто любопытно.
 

 
RAID LSI  
проблема с питанием, просел БП и диски стали вываливаться, пока разбирались в чем проблема файловая система NTFS повела себя странно и часть файлов побилась.  
те что лежали до возникновения проблем с питанием остались нормальными, а вот новые пострадали.  

Всего записей: 481 | Зарегистр. 21-11-2016 | Отправлено: 13:49 16-01-2018 | Исправлено: Domin0, 14:20 16-01-2018
GoblinNN

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

Цитата:
RAR5 с -rr20%  

не понятно мне лично в этих -rr. чем выше процент тем больше шанс восстановить? правильно? и  на этот процент увеличивается размер файла. весь смысл в сжатии теряется. ну ужалось оно все и стал файл меньше на 20%, а мы потом хлоп и добавляем эти же 20%. это так для примера я взял цифру из цитаты. не понятно мне это. смысл то в чем? вот ежели бы откусить эти -rr20% от файла и хранить в другом месте, а потом ежели чего добавить для восстановления и с гарантией что 100% восстановится. тогда да. был бы смысл. и сжатие вроде никуда не делось и восстановить можно. а сейчас что? храним все яйца в одной корзине. побился файл-архив в двух местах. на том месте где -rr и в самих данных и все. я последний год вообще не добавляю параметр -rr. толку от него имхо нет. только вес файла больше да плюс время на создание...

Всего записей: 2905 | Зарегистр. 11-10-2005 | Отправлено: 15:04 16-01-2018
EugeneRoshal

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

Цитата:
не понятно мне лично в этих -rr. чем выше процент тем больше шанс восстановить?

Да.

Цитата:
весь смысл в сжатии теряется.

Кроме сжатия для бэкапа важно удобство работы с одним файлом архива вместо множества мелких файлов. И прочие функции типа шифрования.

Цитата:
ну ужалось оно все и стал файл меньше на 20%

У меня бэкап с основными рабочими данными жмется в 8 раз. Solid архив, много повторов.

Цитата:
смысл то в чем?

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

Цитата:
вот ежели бы откусить эти -rr20% от файла и хранить в другом месте

Внешняя recovery record может быть полезна. Но из этого не следует, что внутренняя - бесполезна.

Цитата:
побился файл-архив в двух местах. на том месте где -rr и в самих данных и все.

Может все, может не все. Смотря как побился.

Всего записей: 2239 | Зарегистр. 29-04-2013 | Отправлено: 16:14 16-01-2018
vasevase

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

Цитата:
Victor_VG: эти уже через год после записи не читаются. Имел с ними дело - из 400 CD-RW DigiteX 12x  

Это от условий хранения (да и записи) ещё зависит, имхо.
Я законсервированные флопари 3'' и 5'' (более 10 летней выдержки, вроде) считывал.
CDR ~12+ летней выдержки (дешёвый "лысый" ноунэйм).

Цитата:
EugeneRoshal: Золотой век RR уходит вместе с флоппи и поцарапанными CD

У меня было относительно недавно два случая:
1) посыпались пару HD (частично скопировал, RR могло пригодиться)
2) по%eRuлся профиль вместе с содержимым; частично восстановил, для архивов пригодилась бы RR.
 
Однако, и реализацию восстановления в WinRar злые языки ругают.
(Там были, помните, тесты с перетасовкой частей тела архива и тому подобное).

Всего записей: 3127 | Зарегистр. 28-08-2010 | Отправлено: 17:50 16-01-2018 | Исправлено: vasevase, 17:58 16-01-2018
Andarin



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
vasevase
У меня к DigiteX (именно CD) тоже отношение плохое, из личного опыта, хотя один CD-R23 16x со мной много чего прошёл, и ещё сейчас ( > 10 лет) вполне себе нормальный. А про флоппики, что из первых 3,5 ", что из 5" - те весьма долговечные были, чисто для хранения, не частой перезаписи. А вот когда стали они уже отходить, то и качество стало отвратительным, особенно нонеймы.

Всего записей: 3065 | Зарегистр. 04-03-2006 | Отправлено: 18:21 16-01-2018
EugeneRoshal

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

Цитата:
(Там были, помните, тесты с перетасовкой частей тела архива и тому подобное).

RAR5 recovery record умеет работать с поврежденными, удаленными и вставленными данными, но перетасовку и правда не поддерживает.  
 
Принципиальных ограничений в формате RR на это нет. Просто такой тип повреждения намного менее вероятен, чем перечисленные выше, а усилий на реализацию требует больше. И не только усилий разработчика, но и затрат времени на поиск потенциально перетасованных данных при восстановлении. Поэтому и не сделано.

Всего записей: 2239 | Зарегистр. 29-04-2013 | Отправлено: 19:14 16-01-2018
V0lt



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
vasevase
Цитата:
тесты с перетасовкой частей тела архива и тому подобное
Тест какой-то нереальной фигни в практическом смысле.

Всего записей: 10450 | Зарегистр. 05-02-2003 | Отправлено: 20:29 16-01-2018
vasevase

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

Цитата:
V0lt: Тест какой-то нереальной фигни в практическом смысле.

С другой стороны, имхо, человек сделал утилитку более полезную,
чем бесконечная обвеска свистульками-п@рдульками старых бесплатных плееров.
 
EugeneRoshal
За что купил, за то продал: подробнее...
Чтиво занимательное/кому-то познавательное.
(Это оттуда же, куда Bulat ссылку давал, если что).
 
В WinRar система создания избыточной информации несколько проще, конечно.
Для "обычных" юзеров, по крайней мере (как минимум, имеется свой GUI).

Всего записей: 3127 | Зарегистр. 28-08-2010 | Отправлено: 22:36 16-01-2018 | Исправлено: vasevase, 23:08 16-01-2018
Pasha_ZZZ



Platinum Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Почему-то при восстановлении RR удаляется, даже если она полностью целая. А в свойствах архива все равно как бы присутствует.
И при тестировании закономерное "данные для восстановления повреждены".
 
Взял архив со 100-мегабайтами (с чем-то) RR, разбил на куски по 95 МБ, соединил без одного куска в середине. RR ведь должна быть полностью живой (она в конце) - но в фиксенном архиве ее нет (даже судя по размеру), а в Свойствах есть, и процент, указанный при создании RR.

Всего записей: 12360 | Зарегистр. 11-03-2002 | Отправлено: 23:29 16-01-2018
EugeneRoshal

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

Цитата:
За что купил, за то продал:
Цитата:
 
Ну вот я взял 3 гига архив winrar5 и привесил туда 30% инфы для восстановления. А потом стер нафиг в конце 300 метров, всего лишь 10%. Решил посмотреть, что получица... К сожалению, WinRAR5 рухнул и пипец.

Я сейчас проверил, ничего не рухнуло. Потом я дополнительно внес 100 повреждений, 10 вставок и 10 удалений до 64кб размером каждое в поврежденный указанным выше способом архив. WinRAR его успешно починил. Правда медленно, минут 40, так как потратил много времени на поиск отсутствующей трети recovery секторов. В принципе тут есть куда оптимизировать по скорости. Просто команда восстановления данных в очереди на оптимизацию по скорости - в конце списка. Используется она раз в пятилетку. Вот добавление recovery record выполняется часто, так оно в RAR и оптимизировано.
 
Правда 100 повреждений, 100 вставок и 100 удалений WinRAR в описанном выше 3гб архиве полностью починить не смог, но у любой защиты данных есть свой предел прочности.

Цитата:
Продолжая изгаляться, я взял свежий архив с 30% избыточной информации, и разделил его на части A и B. Потом склеил обратно, переставив местами, т.е. как BA.

Это да, WinRAR сейчас не умеет.  
 
Из этой же темы того же автора:

Цитата:
Но это не значит, что WinRAR плох на практике, скорее наоборот. Например, я взял архив 3 гига и нанес ему 10000 случайных дыр, и WinRAR все вылечил. Что еще надо? Но в RSC32 пока есть нужное количество блоков и живы заголовки - он непотопляем теоретически - запрещенных к восстановлению комбинаций нет.

Тут интересен момент насчет "пока живы заголовки". Булат как раз про это и писал. Если мы рассуждаем про "непотопляем теоретически", на мой взгляд отталкиваться надо от худшего случая - минимального количества повреждений, которое выводит защиту из строя. У RAR5 в кажом секторе ECC есть полный набор заголовков, требуемых для его работы. То есть, вывести из строя 20 секторов ECC можно только 20 однобайтовыми повреждениями. Если же в программе миллион секторов ECC, но 10 копий критически важных заголовков с контрольными суммами секторов данных, ее реальная устойчивость к множественным повреждениям (10 повреждений) в худшем случае меньше, чем у RAR с 20 секторами (-rr10%). Это безотносительно RSC32, я не знаю, как именно он устроен.
 
Добавлено:
Pasha_ZZZ

Цитата:
Взял архив со 100-мегабайтами (с чем-то) RR, разбил на куски по 95 МБ, соединил без одного куска в середине. RR ведь должна быть полностью живой (она в конце) - но в фиксенном архиве ее нет (даже судя по размеру), а в Свойствах есть, и процент, указанный при создании RR.

Она копируется, только если главный заголовок RR находится на позиции, указанной в главном заголовке архива. Если же она сдвинута, и нам пришлось искать ECC секторы по архиву в ходе восстановления, RAR ее не копирует. Свойства же берутся из главного заголовка архива. Восстановление данных на основе RR работает не с заголовками, а с  секторами, поэтому содержимое заголовков не трогает.
 
При желании это можно потом доработать. Но если команде Repair удалось что-то ценное восстановить, я бы в любом случае распаковал такой архив и сохранил восстановленные данные заново, можно и с -rr.

Всего записей: 2239 | Зарегистр. 29-04-2013 | Отправлено: 14:41 17-01-2018
Bulat_Ziganshin

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

Цитата:
Тут интересен момент насчет "пока живы заголовки"

есть несколько уровней "заголовков":
 
1. то, что я называю "геометрия ECC" - кол-во групп, число src/ecс секторов в них и их отображение на защищаемые файлы. Это можно записать всего в несколько десятков байт. Поэтому в моей утилите они хранятся при каждом секторе ECC.  
 
В par2/rsc32, к сожалению, эта инфа хранится только в суперзаголовке RR. Да, этого суперзаголовка делается куча копий (у rsc32 -hr3 по умолчанию), но если все эти копии накроются - можно ползти на кладбище.
 
RAR, как я понимаю, хранит геометрию при каждом ECC-секторе, т.е. она фактически неубиваема (теряется вместе с самим сектором ECC).
 
 
2. CRC от исходных секторов - с ними возникает описанная мной в соседней теме коллизия. Опять же, afair, par2/rsc32 хранят её в хидер-блоках, которых делается всего несколько копий, а RAR - при каждом секторе ECC. Да, тут есть проблема в виде размера этой инфы, и RAR её обходит, ограничивая число секторов в одной группе сотнями, а не тысячами, как в PAR2, и даже миллионами, как в RSC32.
 
Тут как раз и проявляется то, что RAR - это не суперутилита, выжимающая всё до последней крохи, но в пределах своих ограниченных намерений RAR отлично делает свою работу.
 
 
3. Оглавление самого архива, т.е. список файлов в нём. par2/rsc32 поддерживают защиту коллекций файлов, при этом они сохраняют список обработанных файлов, хотя бы чтобы знать какие сектора ECC каким файлам соответствуют. При потере этой инфы они просто не смогут ничего восстановить. Опять же, они делают всего несколько её копий в вышеупомянутых хидер блоках.
 
Про RAR точно не скажу, но скорей всего он защищает эту инфу как часть архива, т.е. по дефолту у вас будет процентов 10 сего защиты, но зато 20 блоков восстановления, т.е. чтобы потерять хотя бы один блок - надо потерять 20 из 220 блоков этой конкретной группы
 
Плюс прибавьте к этому то, что в новом формате RAR оглавление архива дублируется, что даёт дополнительный уровень защиты. В целом получается далеко не идеально, но вполне достаточно на практике и соответствует общему уровню защиты RAR
 
 
4. Ну и заодно уж скажу про защиту собственно данных. RAR делит исходные данные на сектора по 64 КБ, затем разбивает их на группы по 200 секторов с интерливингом - т.е. сначала идут первые сектора каждой группы, затем вторые сектора каждой группы и т.д. Ну и соответственно при 10% RR у вас получится всего 20 секторов ECC
 
Т.е. схема RAR в целом правильная и даже хорошая, а вот уровень избыточности откровенно мал. Для сравнения в PAR2 до 32К+32K секторов на группу, а в RSC до нескольких миллионов (там ограничение 2 ГБ ОЗУ и размер сектора от 130 байт)
 
Но это ограничение:
 
во-первых позволяет сделать некоторые аспекты защиты принципиально более надёжными, чем это сделано у конкурентов (см. выше) и чем даже теоретически возможно при больших размерах групп (см. соседний тред)
 
во-вторых позволяет обрабатывать данные без временных файлов (привет rsc32) - опять же, быстро обрабатывать группы в тысячи секторов без промежуточного файла того же размера, что RR, на HDD принципиально невозможно
 
в третьих, значительно упрощает реализацию. Евгений сделал весь этот механизм за месяц-два. Учитывая, что он в две руки делает весь RAR от GUI до низкоуровневых алгоритмов, он просто не может себе позволить потратить полгода-год на одну только реализацию RR
 
Добавлено:

Цитата:
Тест какой-то нереальной фигни в практическом смысле.

редкой, но вполне реальной. представьте что у вас рухнула файловая система, т.е. вы получили просто сырой образ диска (или флешки). это означает, что там есть в принципе сектора исходных данных, но идти они могут в любом порядке, хотя как правило будут длинные последовательные куски, но уж между собой жти куски могут быть перемешаны как угодно
 
теперь смотрите, как с этим справляется идеальная утилита (т.е. моя собственная):
 
во-первых, каждый сектор ECC сопровождается информацией о геометрии RR/архива и неким GUID, так что программа восстановления может собрать все выжившие ECC-сектора, сгруппировать их по GUID, и тем самым получить некий набор ECC-файлов
 
во-вторых, каждый сектор ECC включает в себя информацию о CRC некоторых секторов исходного файла, плюс ECC поверх этой инфы. Итого, из выживших секторов ECC можно собрать инфу о CRC некоторых секторов исходного файла, плюс восстановить ещё больше черех механизм ECC
 
на этом этапе у нас есть список CRC части секторов из исходных данных, мы можем пройти по сырому образу и извлечь из него эти сектора. После чего запускается обычных механизм восстановления, который получает на вход выжившие ECC-сектора и сектора данных, имея из метаданных ECC-секторов информацию о том, как эти сектора связаны в группы. Соответственно, восстановив группы в пределах сохранившихся данных, он может записать исходный файл точно в исходном виде
 
 
Как я понимаю, RSC32 нацелен на такой же уровень восстановления, но у него неразвитая защита метаинформации. А RAR неплохо защищает метаинформацию, но в нём не реализован такой изощрённый поиск сохранившихся данных. Хотя я не знаю, может без переставновок он справится?

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 09:29 18-01-2018
Bulat_Ziganshin

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

Цитата:
Мысль сделать внешнюю RR для защиты архивов или произвольных данных периодически возникает. Пусть на основе нынешних RS16 кодов, не заморачиваясь чем-то более продвинутым. Но до реализации пока дело не доходит и когда дойдет - не знаю. Всегда находится что-нибудь более актуальное.  
 

1. готовые библиотеки с отличными хар-ми можно взять у catid, так что это совершенно не проблема
 
2. на базе rar5 несложно сделать однофайловую программу защиты, однако дальше нужно обновлять доку и вести support. спрашивается - кому и зачем это нужно при живых multipar/rsc32?? если уж на то пошло, лучше подумать об универсальных механизмах, упрощающих эксплуатацию из WinRAR разнообразных программ работы с файлами
 
3. защиту наборов файлов хорошо сделать очень трудно, а плохая и так уже есть  так что опять же, не стоит трудозатрат
 
4. а вот внешнюю RR я поддержу. это позволяет управлять уровнем избыточности при пересылке данных, или удалять часть RR со временем (скажем для более старых архивов у нас может быть менее строгая policy). хотя конечно, тут и защиту произвольных одиночных файлов сделать недолго
 
 

Цитата:
не понятно мне лично в этих -rr. чем выше процент тем больше шанс восстановить? правильно? и  на этот процент увеличивается размер файла. весь смысл в сжатии теряется. ну ужалось оно все и стал файл меньше на 20%, а мы потом хлоп и добавляем эти же 20%.


Цитата:
 побился файл-архив в двух местах. на том месте где -rr и в самих данных и все.

 
нет, в идеале RR размером X байт позволяет потерять любые X байт из архива+RR прежде чем появятся невосстановимые ошибки. на практике это более ограничено, но в rar уровень защиты справится с 99.9% реальных случаев потери данных
 
далее, сжатие и RR - вещи вообще перпендикулярные. если у тебя потеряется файл из набора, то его у тебя не будет, сжат он или нет. поэтому сжатие само по себе не ухудшает надёжность хранения, и даже увеличивает, поскольку файлы становятся меньше. Минус конечно солид-сжатие и файлы, которые остаются юзабельными несмотря на частичные потери
 
А RR, неважно поверх сжатых данных или нет, позволяет пережить потерю X байт данных, храня на эти X байт больше. Сжатие+RR увеличивает надёжность хранения данных и сжимает их до минимума, возможного при таком уровне надёжности.
 
Представь это в другом порядке - мы сначала добавляем избыточность, позволяющую восстановить данные, и затем удаляем избыточность, которая данные восстановить не поможет. В результате получаем минимум избыточности, гарантирующую определённый уровень защиты. В экстремальном случае - без RR вообще, получаем абсолютно минимальный уровень избыточности, но без какой-либо защиты. В исходных же данных избыточность есть, а защиты при всём этом нет
 
 

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

насчёт скорости - отмечаешь все CRC секторов данных, в Bloom filter, и дальше получаешь 1 обращение к памяти на один байт данных, т.е. скорость поиска порядка 50-100 МБ/с

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:24 18-01-2018
EugeneRoshal

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

Цитата:
1. готовые библиотеки с отличными хар-ми можно взять у catid, так что это совершенно не проблема

Да, я посмотрел. Но, в общем-то, нынешняя реализация RS16 в RAR на 200 блоках работает быстро, свои задачи выполняет и устраивает меня своей простотой. Увеличивать количество блоков - решать проблему с контрольными суммами.

Цитата:
2. на базе rar5 несложно сделать однофайловую программу защиты, однако дальше нужно обновлять доку и вести support. спрашивается - кому и зачем это нужно при живых multipar/rsc32??

Насчет GUI, доки и саппорта - есть такое дело. С ними мороки зачастую больше, чем собственно с реализацией алгоритма.

Цитата:
3. защиту наборов файлов хорошо сделать очень трудно, а плохая и так уже есть  так что опять же, не стоит трудозатрат
 
4. а вот внешнюю RR я поддержу.  

Про внешнюю RR здесь как-то шла речь, что неплохо бы ее распространить и на группы RAR архивов, в том числе и на RAR тома в качестве замены REV файлов. А если мы делаем поддержку внешней RR для групп RAR архивов, то она у нас получается и для групп любых других файлов. Дальше уже вопрос - хотим ли мы заниматься гуем, доками и саппортом или оставляем это только для архивов. Правда какое-то GUI для групп RAR архивов все равно пришлось бы делать.
 

Цитата:
насчёт скорости - отмечаешь все CRC секторов данных, в Bloom filter, и дальше получаешь 1 обращение к памяти на один байт данных, т.е. скорость поиска порядка 50-100 МБ/с

Я в RAR5 repair хотел сделать расход памяти полностью независимым от размера архива. Чтобы при починке архива в 10 TB мы не вылетели по нехватке памяти на 32-битной системе. Поэтому нынешняя реализация CRC секторов и структуры поиска в памяти не держит, а для поиска сдвинутых секторов заглядывает вперед и назад от текущей точки. В итоге память мы сберегли, но пожертвовали скоростью, так что восстановления 10 TB архива, если в нем много deletions или insertions, можно и не дождаться. Может потом доберусь, займусь оптимизацией ценой некоторого расхода памяти.
 
Про Bloom filter почитал, спасибо, буду иметь в виду, но пока не знаю, использую ли. Это еще расход памяти, зависящий от размера архива.
 
Там у меня еще заморочка, что последний сектор данных может быть меньше предыдущих. Если ничего другого не придумаю, придется два rolling hash вычислять, для обычных секторов и для укороченного.
 
Добавлено:
Bulat_Ziganshin

Цитата:
А RAR неплохо защищает метаинформацию, но в нём не реализован такой изощрённый поиск сохранившихся данных. Хотя я не знаю, может без переставновок он справится?  

Перестановки в пределах одного архива сейчас не реализованы, но реализуемы без изменения формата RR. Но перемешивание данных нескольких архивов нынешним форматом не поддерживается. Для этого и правда нужен уникальный идентификатор и замороченная обработка найденных данных.
 
Добавлено:

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

Посмотрел, там даже не два, а три разных размера секторов. Стандартный, последний в секции и последний в архиве. В принципе тоже решаемо, но не без приключений.

Всего записей: 2239 | Зарегистр. 29-04-2013 | Отправлено: 22:07 18-01-2018 | Исправлено: EugeneRoshal, 12:16 19-01-2018
pikorembo



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
 
Известно, что при загрузке файлов через браузер, они получают специальную метку о том, что "Этот файл получен с другого компьютера и, возможно, был заблокирован с целью защиты компьютера". В Свойствах файла появляется соответствующая надпись и кнопка "Разблокировать".
 
В WinRAR 5.31 была полезная функция (или побочный эффект?), когда файлы, извлекаемые из архива, который был загружен из Интернета, брали данную метку от родительского архива (дописывался NTFS Alternate Data Stream). Это было удобно, так как при запуске исполняемых файлов из архива, полученного из ненадёжного источника, пользователь видел предупреждение системы безопасности, и тем самым снижался риск проникновения зловредов в систему.
 
Начиная с WinRAR 5.40, эта функция таинственным образом перестала работать, даже не осталось упоминания в changelog. Т.е. у загруженного из Интернета архива метка есть, а у извлекаемых файлов она отсутствует. Можно ли вернуть старое поведение в виде опции в Настройках WinRAR?

Всего записей: 279 | Зарегистр. 29-01-2014 | Отправлено: 09:04 19-01-2018 | Исправлено: pikorembo, 09:31 19-01-2018
Uncle KILLER



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
У меня лет 10 строка меню в Far не менялась:
 
R:   Архиватор RAR
     rar a -r -m5 a
 
.. и ничего, живу..

Всего записей: 6501 | Зарегистр. 01-04-2002 | Отправлено: 09:23 19-01-2018
EugeneRoshal

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

Цитата:
В WinRAR 5.31 была полезная функция

По факту оказалось, что вредная. Многие драйверы и программы отказались запускаться. Например, посмотрите второе сообщение здесь:
https://rog.asus.com/forum/showthread.php?36977-How-to-Install-Ai-Suite-3!-(For-People-Who-Cannot-install-the-new-AI-Suite-3)/page5
Мне и про другие подобные программы писали. Сейчас уже не вспомню названия, но их хватало. Какой-то специальный университетский софт, программы, связанные с безопасностью, прочие. В итоге страдала репутация WinRAR, так как при распаковке другими архиваторами этой проблемы не было. В итоге я оставил эту функцию только для офисных форматов (.doc*, .xls*, ...).

Цитата:
Можно ли вернуть старое поведение в виде опции в Настройках WinRAR?

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

Всего записей: 2239 | Зарегистр. 29-04-2013 | Отправлено: 11:46 19-01-2018
maxvlas



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
WinRar может тестировать образы или нет?
тут Редактирование образов CD/DVD/BD (ISO, BIN/CUE и т.д.) читал так и не понял.
 
один пишетTCPIP
Цитата:
Винраром не получится, кнопка Test неактивна..

Другой, gav ru 6a
Цитата:
Просто для примера возьми любой образ открой его в HEX редакторе и замени какие либо байты на 00 winrar скажет что все отлично


Всего записей: 7934 | Зарегистр. 08-02-2011 | Отправлено: 09:28 22-01-2018 | Исправлено: maxvlas, 10:02 22-01-2018
Aniskin

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

Цитата:
WinRar может тестировать образы или нет?  

Наверное, WinRar может лишь проверить на наличие файлов и соответствие их размеров. Но целостность образа нет, поскольку формат ISO (о нем речь?) не содержит контрольных сумм всего образа или контрольных сумм файлов. Т.е. сверять не с чем.

Всего записей: 612 | Зарегистр. 09-01-2006 | Отправлено: 12:04 22-01-2018
Domin0



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

Цитата:
WinRar может тестировать образы или нет?  

а что там тестировать? контрольных сумм же нет, просто читается ли он с диска?

Всего записей: 481 | Зарегистр. 21-11-2016 | Отправлено: 13:54 22-01-2018 | Исправлено: Domin0, 13:54 22-01-2018
   

Страницы: 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 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199

Компьютерный форум Ru.Board » Компьютеры » Программы » WinRAR (часть 3)
Maz (27-08-2020 19:31): WinRAR (часть 4)


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru