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

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

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

Maz (31-07-2023 08:32): WinRAR (часть 5)  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 200 201

   

Maz



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



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

Текущая английская бета-версия:  6.23 beta 1 x86 | x64
Текущая русская бета-версия:  6.23 beta 1 x86 | x64

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

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

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

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

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

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

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

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

Всего записей: 38814 | Зарегистр. 26-02-2002 | Отправлено: 19:30 27-08-2020 | Исправлено: DimmY, 17:47 20-07-2023
EugeneRoshal

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

Цитата:
Как в SFX в комментарии, прописать удаление разделов в реестре.
Вроде где то встречал такое, но сейчас найти не могу.

Специальной команды на этот счет в SFX модуле нет.

Цитата:
как они все три перестают удалять 32 битную ветку

У reg есть ключи /reg:32 и /reg:64. Возможно в вашем случае нужен /reg:32

Цитата:
Я пробовал только немного по другому:
Setup=<Hide>REG DELETE HKEY_LOCAL_MACHINE\ - ошибка: Не удается найти "<Hide>REG'

Убедитесь, что версия default.sfx - 6.00 или новее.

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 18:47 24-05-2021
BKPB

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
 
Подскажите, почему я не могу удалить или отредактировать в комментарии SFX архива строку:
;Расположенный ниже комментарий содержит команды SFX-сценария
Когда я создаю SFX архив путём добавления в него файлов, то я могу удалить эту строку без проблем.
Но сейчас для удаления записи в реестре я создал архив SFX путём преобразования архива WinRar.
И вот в этом случае отредактировать или удалить строку:  
;Расположенный ниже комментарий содержит команды SFX-сценария, не получается.

Всего записей: 240 | Зарегистр. 11-06-2014 | Отправлено: 19:24 24-05-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKPB
Откройте архив в WinRAR и используйте команду "Add archive comment" в меню "Commands". Она же вызывается с помощью Alt+M. Если комментарий уже существует, эта команда позволяет его редактировать. Если же эта команда недоступна, возможно дальнейшая модификация архива ранее была заблокирована опцией "Lock archive".

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 20:47 24-05-2021
Ldsuyiwe

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

Цитата:
 
EugeneRoshal
 
Возможно ли в будущих версиях сделать?:
1. дополнительный графический диалог для ручной сортировки файлов.
2. алгоритм поиска не только одинаковых файлов, но и наиболее похожих по содержимому,
что бы такие файлы упаковывались подряд, за счёт чего повысилась бы степень сжатия,
без смены основного алгоритма.
 

 
Хочу поддержать просьбу по пункту 2, для архива виртуальных машин пользуюсь zpaq.exe
жмет очень хорошо, разбивает файлы на блоки и для каждого считает хэш.
 
Хочу добавить свои хотелки.
1. Переработать расчет оставшегося времени сжатия, добавить оценку IOPS диска
    а то когда сжимает группу мелких файлов, то время уходит в бесконечность
    для HDD  Очень приблизительно Time =  0,05сек * CountFile + AllSize / LineSpeedRead
2. в окошке прогресса сжатия где меняется степень сжатия добавить топ расширений
   не сжимаемых файлов для возможности их включить online  в список без сжатия
3. Если сортировать мелкие файлы по порядку расположения Кластеров на диске HDD
    ускорение было бы в разы, мог бы помочь с алгоритмом для NTFS
4. Добавить функционал MultiPar - генерацию данных для восстановления хотя бы для
    одного файла создать несколько томов восстановления

Всего записей: 13 | Зарегистр. 09-12-2015 | Отправлено: 18:35 26-05-2021
uShell

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

Цитата:
Хочу поддержать просьбу по пункту 2

Вместо похожих по содержимому файлов можно внедрить в алгоритм rep/srep (поиск совпадений на больших расстояниях). Степень сжатия будет даже лучше.
 

Цитата:
добавить оценку IOPS диска
    а то когда сжимает группу мелких файлов, то время уходит в бесконечность

Можно раздельно оценивать время на открытие, на чтение и на сжатие, а оставшееся время архивирования рассчитывать по трём этим параметрам. Но на время будут сильно влиять кэширование и степень сжимаемости. Кстати, вопрос к EugeneRoshal: при расчёте времени учитывается ключ -ms (т.е. что некоторые файлы будут копироваться, а не сжиматься)?
 

Цитата:
по порядку расположения Кластеров на диске HDD

Отдельные алгоритмы надо делать не для разных файловых систем, а для разных операционных систем. Под Windows это будет вызов FSCTL_GET_RETRIEVAL_POINTERS. Но отдалённость кластеров иногда не соответствует отдалённости физических секторов. Возможные причины: remap, составные тома, особое хранение файла (например, резидентный в NTFS). Плюс непонятно, что делать с фрагментированными файлами (8 КБ - маленький файл или нет?). Я бы предложил другой подход: при сортировке файлов читать все маленькие файлы в буфер - так они попадут в кэш, - а большие при сжатии открывать без буферизации (чтобы кэш не опорожнялся).

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 20:30 26-05-2021
EugeneRoshal

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

Цитата:
Переработать расчет оставшегося времени сжатия, добавить оценку IOPS диска

Оценивать IOPS диска (с треском запускать сотню seeks?) это, на мой взгляд, немного перебор для архиватора. Кроме того, если файлы в дисковом кэше, при этом подходе мы опять ошибемся с прогнозом, только теперь в излишне пессимистическую сторону.

Цитата:
Если сортировать мелкие файлы по порядку расположения Кластеров на диске HDD
    ускорение было бы в разы

Как тогда быть с solid архивами, где ради увеличения сжатия файлы сортируются по расширению и rarfiles.lst. Да и не в solid файлы традиционно добавляются в порядке, указанном пользователем, и другой подход может оказаться непривычным.
 
uShell

Цитата:
Я бы предложил другой подход: при сортировке файлов читать все маленькие файлы в буфер

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

Цитата:
а большие при сжатии открывать без буферизации (чтобы кэш не опорожнялся)

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

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 21:39 26-05-2021
Ldsuyiwe

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

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

 

Цитата:
Оценивать IOPS диска (с треском запускать сотню seeks?) это, на мой взгляд, немного перебор для архиватора. Кроме того, если файлы в дисковом кэше, при этом подходе мы опять ошибемся с прогнозом, только теперь в излишне пессимистическую сторону.  

 
Все предложения не для тысячи файлов ,а для нескольких сот тысяч и миллионов при резервном копировании (нет разницы ждать 1 или 3 минуты, но есть 1 и 3 часа ). Тогда файлов с одним расширение может набраться десятки тысяч и сортировать их уже в пределах группы по расположению по кластерам, и при таком количестве про кэш можно не обсуждать.  
 
Добавлено:
Возможно мене кажется, но хочу уточнить.
При генерации томов для восстановления, допустим для 800 файлов по 1 гигабайту
создаются 20 томов, rar занимает в памяти 100 мегабайт, на диск HDD идет максимальная нагрузка
в 150 IOPS, процессор грузится примерно на одно ядро.
Как я понимаю файлы архива 800 штук читаются параллельно, если увеличить внутренний буфер для чтения каждого файла архива (в 10 раз пусть rar занимает 1 гигабайт) для снижения IOPS диска, должна увеличиться скорость.

Всего записей: 13 | Зарегистр. 09-12-2015 | Отправлено: 22:12 26-05-2021
insorg



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

Цитата:
внедрить в алгоритм rep/srep
Эх, мечты... А лицуха позволяет?  
Хотя, идея была бы офигенная, но это очередная смена формата, опять отломанная совместимость, и т.д.. Впрочем, если такие архивы обозвать не .rar, а .rsr (rar+srep/rep), то и путаницы не должно быть. Но это, опять таки, если позволяет формат архива или ещё какие-то условности.
Я ещё на просторах сети встретил ещё один интересный обработчик - логическое продолжение srep от другого прогера - LOLZ. Название тупое, гуглится крайне паршиво, но в репаках игр стал появляться почти повсеместно в freearc контейнерах, и я вынужден признать его достаточно неплохую эффективность.
Так что я вижу такое "внедрение" крайне интересным. Лишь бы технически это можно было исполнить и не нарваться на внезапные баги.

Всего записей: 16541 | Зарегистр. 04-11-2010 | Отправлено: 08:45 27-05-2021 | Исправлено: insorg, 08:49 27-05-2021
uShell

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

Цитата:
А если пользователь незадолго до упаковки работал с этими большими файлами

Если размер некоторых файлов превышает размер кэша, то чтение с кэшированием первого же из них может вытеснить из кэша все остальные. Я говорю "может", потому что не уверен, что ОС будет пытаться кэшировать всё подряд, но если это так, со второго большого файла кэширование можно отключать. Как вариант, если WinRAR читает файлы поблочно, а не побайтово, можно предусмотреть ключ наподобие -nc<size>, выставляющий FILE_FLAG_NO_BUFFERING для файлов больше заданного размера.
 
Вообще, моя изначальная мысль по поводу запрета кэширования больших файлов заключалась в том, чтобы из кэша не вытеснялись каталоги и открытие файлов осуществлялось максимально быстро. Опять-таки, может, ОС достаточно умна, чтобы не вытеснять индексы при чтении файлов, но уверенности в этом нет.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 09:30 27-05-2021
EugeneRoshal

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

Цитата:
Как я понимаю файлы архива 800 штук читаются параллельно, если увеличить внутренний буфер для чтения каждого файла архива

Там 64 Мб буфер на все тома. Если вместо 800 взять более жизненное количество томов в 128, на каждый будет выполняться чтение блоками в 512 кб.

Цитата:
(в 10 раз пусть rar занимает 1 гигабайт) для снижения IOPS диска, должна увеличиться скорость.

Безусловно. А если мы увеличим буфер до 10 гб, скорость еще немного вырастет.
 
Как обычно в таких ситуациях размер буфера это компромисс между расходом памяти и количеством позиционирований диска. На данный момент он выбран на уровне 64 мб. Может в будущем он и увеличится, пока сказать не могу. Но и о расходе памяти забывать нельзя.
 
uShell

Цитата:
Если размер некоторых файлов превышает размер кэша, то чтение с кэшированием первого же из них может вытеснить из кэша все остальные. Я говорю "может", потому что не уверен, что ОС будет пытаться кэшировать всё подряд

При упаковке RAR открывает файлы с FILE_FLAG_SEQUENTIAL_SCAN. Это увеличивает размер предвыборки и позволяет убирать из кэша данные перед текущей позицией файла:
https://devblogs.microsoft.com/oldnewthing/20120120-00/?p=8493

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 12:17 27-05-2021
Ldsuyiwe

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

Цитата:
Там 64 Мб буфер на все тома. Если вместо 800 взять более жизненное количество томов в 128, на каждый будет выполняться чтение блоками в 512 кб.  

 
То есть имеем 128 томов на чтение плюс 5 томов восстановления на  запись итого минимум
132 IOPS для диска - практически потолок для среднего HDD, при этом запись плюс чтение  
ограничена 60-100 мег/сек - если увеличим буфер до 128 мег, то скорость увеличится до максимальной линейной для HDD.

Всего записей: 13 | Зарегистр. 09-12-2015 | Отправлено: 14:13 27-05-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
 
Даже если приложение использует побайтный режим дискового I/O, аппаратура всё равно будет использовать блочный режим обмена с устройством т.к. любые дисковые/ленточные накопители это блочные устройства с размером блока равным размеру физического сектора на носителе и минимальный размер адресуемой на нём ячейки хранения для неё равен одному физическому сектору накопителя. А дальше вся обработка (адресация и извлечение нужного машинного слова/байта/бита) идёт в буфере I/O средствами ОС в ОЗУ машины.
 
Данное ограничение накладывается шириной адресной шины пространства I/O и архитектурой подсистемыы I/O процессора. Если в системе используется несколько процессоров - например кроме ЦП используются отдельные канальные процессоры I/O, то ограничения накладываются минимальными возможностями одного из них ещё на стадии проектирования ЭВМ.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Всего записей: 33205 | Зарегистр. 31-07-2002 | Отправлено: 18:09 27-05-2021 | Исправлено: Victor_VG, 18:19 27-05-2021
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Victor_VG
Тут дело именно в приложении: для использования FILE_FLAG_NO_BUFFERING надо запрашивать у ОС целое число кластеров. Если в WinRAR не предусмотрена своя буферизация, заведомо кратная размеру кластера, то запрет буферизации потребует серьёзной модификации кода.
 
Ну и позволю себе к Вам придраться:

Цитата:
минимальный размер адресуемой на нём ячейки хранения для неё равен одному физическому сектору накопителя

это неверно для 512e - лучше говорить о виртуальном секторе.

 
Добавлено:
EugeneRoshal
Хотел бы высказать ещё одно пожелание для будущих версий: при замене файлов сохранять состояние атрибута "Сжатый" (конечно, если не задан ключ -oc). Сейчас WinRAR удаляет файл и создаёт его заново. Если файл не удалять, а открыть в режиме CREATE_ALWAYS, то атрибут C, вроде бы, должен сохраниться (а атрибут "Разреженный", вроде, должен сброситься). Только меня смущает слово Combines в MSDN:

Цитата:
Combines the file attributes and flags specified by dwFlagsAndAttributes with FILE_ATTRIBUTE_ARCHIVE and the existing file attributes

UPD: оказывается, это поясняется в DDK:

Цитата:
specified file attributes are logically ORed with those already on the file

Только непонятно, относится ли это к Compressed.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 21:13 27-05-2021 | Исправлено: uShell, 18:41 29-05-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
 
Это верно для любого физического блочного устройства. А технология Advanced Format это просто программная надстройка реализуемая средствами прошивки процессором  контроллера HDD. При её использовании сначала в буфер контроллера на плате управления HDD читается весь физический сектор, при необходимости в нём читается/модифицируется нужный сегмент, при чтении сегмент передаётся на выходную шину, либо при записи модифицированный сектор целиком пишется на пластину HDD.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Всего записей: 33205 | Зарегистр. 31-07-2002 | Отправлено: 00:53 28-05-2021
EugeneRoshal

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

Цитата:
Хотел бы высказать ещё одно пожелание для будущих версий: при замене файлов сохранять состояние атрибута "Сжатый"

При перезаписи файла при распаковке WinRAR сбрасывает все старые атрибуты и в зависимости от опций (ключи -ai, -oc, -ac) либо берет их из архива, либо оставляет сброшенными. Чем в этом плане Compressed отличается от прочих атрибутов типа Hidden или System?

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 17:32 28-05-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
 
Тут есть отличие, но только на NTFS - установка атрибута Compressed (Сжатый) вызывает встроенную в драйвер NTFS.sys процедуру LZ77 сжатия, но сжатые файлы и каталоги хранятся чуть по разному - для каталогов просто ставится атрибут Compressed и если установлен флаг рекурсивности сжатия, то сжимаются зарегистрированные в нём файлы, кроме тех, для которых в данный момент установлена блокировка по записи или по спискам Access Control List (ACL) и выставляется атрибут Compressed для вложенных каталогов с одновременным сжатием зарегистрированных в них файлов с учётом блокировки по записи и ACL. Атрибут Comptressed записывается в записи файлов и каталогов в обе копии MFT и при необходимости копируется в скрытый поток <filename>::$ATTRIBUTE_LIST (доступ по чтению/записи к данному потоку имеет только ОС) находящихся в данной ветви дерева каталогов файлов.
 
Кроме того, для новых файлов атрибут Compressed наследуется от родительского каталога с учётом флага рекурсивности - если для родительского каталога выставлена рекурсия сжатия, то все новые файлы и каталоги записываемые него операциями Write() или Copy() сжимаются, исключением из данного правила является операция перемещения файлов и каталогов Move() - для перемещённых объектов сохраняются все имеющиеся на момент старта операции файловые атрибуты, но физичекого перемещения данных на томе не происходит, а сама операция выполняется в MFT путём добавления в запись каталога приёмника новых объектов и изменением в их записях файлов и каталогов имени родительского каталога на новый.
 
А атрибуты Hidden / System несут совсем иной смысл - Hidden - объекты не отображаются при стандартном просмотре файловой системы (если не включён показ всех, включая скрытые и системные объекты), а System указывает на то, что данный объект является часть операционной системы. Также оба атрибута Hidden и System учитываются при резервном копировании.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Всего записей: 33205 | Зарегистр. 31-07-2002 | Отправлено: 18:31 28-05-2021 | Исправлено: Victor_VG, 18:46 28-05-2021
uShell

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

Цитата:
При перезаписи файла при распаковке WinRAR сбрасывает все старые атрибуты

Да, логика понятна. Моё предложение как раз направлено на изменение этой логики. Быть может, имеет смысл ввести ключ -ai2, который бы не выставлял атрибуты по умолчанию, а сохранял старые?
 
И ещё замечание. Допустим, я распаковываю файл со сброшенным атрибутом Compressed в каталог с установленным атрибутом Compressed (случай нетипичный, но возможный) с ключом -oc и без ключа -ai. WinRAR 6.01 даст сжатый файл, что соответствует описанию ключа -oc:

Цитата:
Set NTFS Compressed attribute

т.е. взводит, если он есть. Однако дальше в описании фраза менее определённая:

Цитата:
This switch allows to restore NTFS Compressed attribute

которую можно понять и как восстановление статуса атрибута, а не только взведённого состояния. Мне кажется, что было бы логичным при отсутствии атрибута Compressed в архиве форсировать его сброс.
 
Скорее всего, мои предложения попадут в категорию "большинству пользователей это не нужно", но всё-таки рад возможности их высказать.
 
Добавлено:

Цитата:
при необходимости копируется в скрытый поток <filename>::$ATTRIBUTE_LIST

Не совсем понял смысл этой фразы. Атрибут Compressed сидит в потоке $STANDARD_INFORMATION, который, вроде бы, всегда резидентный и в $ATTRIBUTE_LIST не вытесняется. С другой стороны, каждый нерезидентный поток имеет свой атрибут Compressed, но на практике я видел его выставленным только для потока $DATA, а $ATTRIBUTE_LIST остаётся несжатым.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 19:11 28-05-2021 | Исправлено: uShell, 19:13 28-05-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
 
При работе с атрибутом Compressed нужно учитывать логику обработки состояния Compressed целевого каталога в файловой системе NTFS:
 
If IsAttrr(Comprtessed) == True and IsCompressFlag(AllFilesOnThisDir) == True Then Write(File, Compress(True)) Else Write(File, Compress (Inherit)) End
 
В противном случае имеем шанс получения ошибки в составляющих любую операцию NTFS цепочке транзакций, вероятнее всего рассогласование результатов транзакции записи в MFT и данных файла, что приведёт к автоматическому вызову обработчика ошибок NTFS с высокой вероятностью установки флага Dirty для данного тома. А установленный флаг Dirty в свою очередь ведёт к безусловному вызову процедуры chkdsk() из драйвера NTFS либо при следующем запуске ОС, либо монтировании файловой системы данного тома в зависимости от того, какое событие наступит раньше.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Всего записей: 33205 | Зарегистр. 31-07-2002 | Отправлено: 20:06 28-05-2021
EugeneRoshal

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

Цитата:
Скорее всего, мои предложения попадут в категорию "большинству пользователей это не нужно", но всё-таки рад возможности их высказать.

В целом - да, я не помню, чтобы раньше просили опцию наследования атрибутов перезаписываемого файла. В своих пользовательских задачах я бы тоже вряд ли нашел, где ее применить. Если будут предлагать, можно будет подумать на этот счет.
 
Что касается принудительной очистки "Compressed" для -oc вместо использования значения по умолчанию, наследуемого от родительского каталога, логика в этом есть. Но, подозреваю, возможны ситуации, когда такой подход поломает существующие сценарии. Например, любитель NTFS сжатия плюс к установке Compressed на весь диск мог прописать -oc в какие-то командные файлы или настройки RAR и WinRAR, исходя из того, что хуже от этого точно не будет, а в каких-то ситуациях может быть и лучше. А тут вдруг окажется, что хуже все же может быть, и многие архивы неожиданно начнут распаковываться со сброшенным Compressed. Пока не знаю, стоит ли оно того.

Всего записей: 2256 | Зарегистр. 29-04-2013 | Отправлено: 21:10 28-05-2021
uShell

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Только что заметил: при извлечении с заменой из CAB-архива атрибут Compressed остаётся как был. Меня такое поведение устраивает, но если Вы хотите, чтобы старые атрибуты сбрасывались, имеет смысл поменять соответствующий код.

Всего записей: 1013 | Зарегистр. 12-06-2019 | Отправлено: 22:46 28-05-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 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 200 201

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


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru