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

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

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

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

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

Версия 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)

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

Всего записей: 37447 | Зарегистр. 26-02-2002 | Отправлено: 19:30 27-08-2020 | Исправлено: DimmY, 21:28 10-10-2021
Fenrizz



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В принципе да, Тотал так может.
 
TOTALCMD64.EXE /S=S:= C:\Backup\File.rar C:\WORK\
 

Всего записей: 410 | Зарегистр. 12-09-2017 | Отправлено: 16:47 17-02-2021 | Исправлено: Fenrizz, 16:55 17-02-2021
EugeneRoshal

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

Цитата:
А если сделать эту опцию по-умолчанию выключенной?

Безусловно, если такая опция когда-нибудь будет реализована, она должна быть выключена по умолчанию.
 
А в случае обычного тестирования, а не тестирования после упаковки, к ней еще больше вопросов. И интерфейс команды тестирования пришлось бы как-то переделывать для запроса пути к файлам на диске. И времени после создания архива прошло больше, а значит выше шансы, что файлы на диске уже изменились.
 
insorg

Цитата:
Хотя, в целом была бы очень полезна фича именно прямого сравнения файлов побайтово, а не только через хеши.

По сравнению с криптографическим хэшем типа Blake2 такая опция может быть полезнее только в случае, если при упаковке мы прочитали файл с диска неправильно, а при тестировании - правильно. Но ведь возможна и обратная ситуация, и тогда WinRAR будет ругаться на корректный архив.
 
Потом, если не сбрасывать дисковый кэш для исходных файлов, мы и во второй раз с большой вероятностью прочтем из кэша те же данные, что и в первый. А если сбрасывать для каждого исходного файла, так на HDD это те еще тормоза. Это не у архива один раз сбросить. Кроме того, при сбойном диске для свежезаписанного файла правильные данные могут оказаться именно в дисковом кэше, а не на диске.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 20:58 17-02-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
 
Согласен, а с SSD несмотря на большую скорость чтения вероятность ошибки ячейки выше чем у HDD т.к. контроллер SSD использует только бит чётности блока в целом (это снижает износ ячеек) и кроме того при снижении физического размера ячейки вероятность её ошибки из-за попадания в неё электрически заряженной частицы или помехи по питанию возрастает прямо пропорционально снижению заряда её переключения, а HDD применяет коды Рида-Соломона для каждого сектора, да и участок записи включает в себя множество отдельных магнитных доменов (МД) что снижает влияние перемагничивания отдельного МД на содержимое ячейки. Так что вероятность внутренней ошибки SSD выше, чем вероятность чтения/записи ошибочного бита на магнитный накопитель.
 
P.S.
 
Ща "знатоки" набегут - шум подымут!

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2667/C602J/16 GB REG ECC DDR3-1866/GTX 1660, i7-2600/z68/16 Gb DDR3-1600/GTX 1060 3Gb

Всего записей: 29434 | Зарегистр. 31-07-2002 | Отправлено: 00:19 18-02-2021
Altus

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

Всего записей: 327 | Зарегистр. 06-09-2006 | Отправлено: 03:45 04-03-2021
insorg



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Altus
Цитата:
распаковка с установкой атрибута "сжатый" у файлов, не работает для самораспаковывающихся архивов
Но зачем? На HDD это - дикая фрагментация и падение скорости, на SSD - повышенная нагрузка при записи. В чём смысл?
Я ещё пойму "прицельное" сжатие некоторых поддающихся этому файлов (с последующей дефрагой, если HDD), но оставлять его где надо и не надо... Это больше вредно, чем полезно.

Всего записей: 1972 | Зарегистр. 04-11-2010 | Отправлено: 10:17 04-03-2021
Inoz2000



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
У sfx-модулей опции распаковки задаются в комментарии. Их совсем немного. И отдельной команды для сжатых файлов нет. Никогда не задумывался о её необходимости.
Галочку для сжатия в диалоге распаковки всегда держу включённой и считаю эту опцию нужной и полезной.

----------
Мы все умрём. (-:

Всего записей: 3460 | Зарегистр. 23-04-2009 | Отправлено: 22:40 04-03-2021
EugeneRoshal

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

Цитата:
Как я понял, распаковка с установкой атрибута "сжатый" у файлов, не работает для самораспаковывающихся архивов.

По умолчанию установка этого атрибута выключена и в RAR/WinRAR, так что включать это по умолчанию в SFX было бы непоследовательно. Разве что опцией, но, по-моему, это первая такая просьба в отношении SFX архивов за много лет.
 
SFX же больше используются для инсталляторов или передачи данных кому-то без распаковщика .rar архивов. Собственные архивы проще хранить в обычном не-SFX виде. А принимать решение по поводу "Compressed" за другого пользователя это, на мой взгляд, спорный подход. Как справедливо указали выше, у "Compressed" хватает и минусов.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 11:57 05-03-2021
insorg



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
WinRAR and RAR 6.01 beta version
WinRAR 6.01 beta 1 is available in English (32 bit, 64 bit).

Всего записей: 1972 | Зарегистр. 04-11-2010 | Отправлено: 13:17 05-03-2021
Altus

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

Цитата:
Разве что опцией, но, по-моему, это первая такая просьба в отношении SFX архивов за много лет.

 
Буду очень благодарен если это станет возможным.
 
Если надо согласия пользователя на работу ключа настроенного автором, то может тогда добавить как установленную дефолтом галку в первом же окне. Хотя по мне так хватило бы и предупреждения, всё таки автор инсталлятора лучше понимает сценарии использования. И при создании такого sfx архива сделать это не галкой в интерфейсе sfx, а тем же ключём "-oc" вот в том поле на вкладке "опции" (это лишь пример, я не настаиваю что именно так правильно), чтобы только тот кто понимает что делает мог это использовать, т.к. придётся справку по ключам сначала почитать.
 
Тут немного оффтопа о сжатии в NT.

Всего записей: 327 | Зарегистр. 06-09-2006 | Отправлено: 16:11 05-03-2021
makemann

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

Цитата:
WinRAR and RAR 6.01 beta version.

 
Под ХП работает?

Всего записей: 81 | Зарегистр. 01-02-2021 | Отправлено: 16:41 05-03-2021
EugeneRoshal

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

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

Мне, как разработчику, сложно представить сценарий, при котором я захотел бы включить NTFS сжатие для каких-то файлов на компьютере пользователя. Такое сжатие это ведь набор компромиссов, и тут, на мой взгляд, инициатива должна исходить от самого пользователя.

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

Я NTFS сжатием пользуюсь разве что для тестирования соответствующей опции в WinRAR. Но, судя по отзывам в сети, это сжатие может приводить и к повышенной фрагментации, и к повышенному износу SSD из-за двухкратной записи:
https://superuser.com/questions/1136329/ntfs-compression-on-ssd-ups-and-downs
 
Насколько это соответствует истине в свежих версиях Windows, я не знаю.

Цитата:
Диск это самое тормозное устройство в любом случае, поэтому сокращение операций чтения|записи ускорит его работу.

Про чтение - если это не PCIe SSD. Про запись, так в ссылке выше пишут:
"It will kill SSD musch faster, since it makes two writes; NTFS compression allways writes uncompressed data prior to start compression on RAM and then re-write compressed data only if it is a gain of at least 4KiB".
Опять же, я не могу подтвердить или опровергнуть эту информацию.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 18:28 05-03-2021
insorg



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

Цитата:
инициатива должна исходить от самого пользователя
Правильно! Хочешь получить ntfs-жатый файл - поставь ты атрибут "сжатый" на целевую папку. Всё. Никаких проблем.
А принудительное вмешательство в артибуты файлов, которые я не просил, это - крайне плохая идея. И если R/H/S ещё норм, то остальные трогать не стоит.
 

Цитата:
сжатие может приводить и к повышенной фрагментации, и к повышенному износу SSD из-за двухкратной записи
И может, и приводит, это факт. Оно так работает - сначала пишем обычный поток данных, потом отбрасываем (переназначаем) лишнее, пишем поверх сжатое и помечаем разницу как свободное. Немного упрощённо, но принцип такой.
 

Цитата:
 "It will kill SSD musch faster, since it makes two writes; NTFS compression allways writes uncompressed data prior to start compression on RAM and then re-write compressed data only if it is a gain of at least 4KiB".
Опять же, я не могу подтвердить или опровергнуть эту информацию.
Всё верно. Так и есть. Подтверждаю практикой, ещё со времён Win2000  в этом плане ничего не поменялось, принцип работы всё тот же. Писать "сразу жатое" (пока что?) нельзя, по крайней мере в нынешней версии NTFS.
 

Цитата:
если это не PCIe SSD
Про SSD - пофиг. Упор будет в проц.
Из практики:
На топовых лучших процах чтение сейчас упирается в 100-200 МБайт/с в базарный день и при отличной погоде на Марсе. Чаще - ещё хуже. Даже на обычном HDD с терабайтными пластинами достижима такая скорость в начале диска. Если же взять даже самый простой дешманский SSDюк на TLC или (о, ужас!) QLC, то разница будет ещё более заметна, диск будет простаивать, ждать пока проц перелопатит жимку в нежимку и только тогда читает дальше. А при записи - это только большее количество записанных данных, а не наоборот. Тем более, что более-менее НЕдревние SSDюки сами на уровне контроллера способны пожать (откинуть лишнее) записываемое во флеш для экономии ресурса.  
Профит здесь чисто условный. Это удобно разве что для какой-нибудь несколько-сот-гиговой папки с установленными играми, на которые можно навесить ntfs-сжатие (и обязательно провести дефраг после этого!) для экономии места. Да и то, только на HDD. И далеко не всегда. И при обязательном условии, что жатое предполагается только читать, а запись либо отсутствует, либо крайне минимальная.

Всего записей: 1972 | Зарегистр. 04-11-2010 | Отправлено: 19:06 05-03-2021 | Исправлено: insorg, 19:12 05-03-2021
AlexDAT



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Altus сейчас посмотрел документацию. Есть более широкие возможности сжатия. Так что для SFX архивов можно использовать отдельный скрипт, программу или в качестве запускаемой программы.
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/compact
Русский вариант документации есть, но переведён машинным переводом, что создало ошибочный перевод команд.
Описание сжатия здесь:
https://docs.microsoft.com/windows/win32/cmpapi/using-the-compression-api
Также нактнулся на https://github.com/ImminentFate/CompactGUI


В справке к архиватору не указан вариант алгоритма для этого атрибута. Скорее всего, используется стандартный вариант XPRESS4K. Если функция востребована, то можно подумать над её улучшением.

Всего записей: 2416 | Зарегистр. 21-04-2009 | Отправлено: 21:00 05-03-2021
EugeneRoshal

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

Цитата:
Описание сжатия здесь:
https://docs.microsoft.com/windows/win32/cmpapi/using-the-compression-api

Это похоже на API сжатия данных общего назначения, а не именно для установки FILE_ATTRIBUTE_COMPRESSED.

Цитата:
В справке к архиватору не указан вариант алгоритма для этого атрибута. Скорее всего, используется стандартный вариант XPRESS4K.

WinRAR использует FSCTL_SET_COMPRESSION с COMPRESSION_FORMAT_DEFAULT, как указано здесь: https://docs.microsoft.com/en-us/windows/win32/fileio/compression-state

Цитата:
Если функция востребована

Не особо.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 21:45 05-03-2021
Altus

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

Цитата:
Мне, как разработчику, сложно представить сценарий, при котором я захотел бы включить NTFS сжатие для каких-то файлов на компьютере пользователя.

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

Цитата:
не могу подтвердить или опровергнуть эту информацию

Да, там конечно доля правды есть, но лишь доля, сложно комментировать например: "When you copy or move a compressed NTFS file to a different folder, NTFS decompresses the file", это очень смешной пассаж, перемещение в пределах диска это смена записи каталога у файла и происходит исключительно в mft. Да и фрагментация на ssd неважна из-за оптимизации износа самим накопителем, важно обеспечить работу trim и не заполнять диск под завязку, что полезно и для самой файловой системы.
 
AlexDAT

Цитата:
Есть более широкие возможности сжатия.

Да, есть, но например максимальное lzx сжатие нормально работает только для ридонли файлов и не наследуется при изменении файла, в отличии от дефолтного алгоритма. Подумалось сейчас, а может некоторые недовольные экспериментаторы из статей выше именно им и пользовались, потому и упирались в какие-то из этих ограничений? Это многое объяснило бы.
 
Но это дело десятое, для текстовых и изменяемых файлов вполне достаточно дефолтного сжатия, да и костылик то я сразу сделал, просто мне казалось если архивируется с пониманием на каких файлах установлен атрибут "сжатый", то логично что и распаковывать можно было бы так же, независимо от используемого "модуля" для распаковки, unrar, winrar, или sfx. Собственно, только поэтому и решил уточнить.

Всего записей: 327 | Зарегистр. 06-09-2006 | Отправлено: 08:05 06-03-2021
EugeneRoshal

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

Цитата:
Надо наверно уточнить, что это не для широкого использования, а во внутренней сети

Просто SFX это чаще для кого-то. А для личного использования обычно хранят .rar, а не .exe.
 
Впрочем, может в будущем имеет смысл подумать над командой "Switches" в SFX. Чтобы можно было указать "Switches=-oc" в комментарии к архиву. Конечно, не только ради -oc, а и для и прочих ключей. Правда надо будет сначала оценить, насколько это увеличит размер SFX модуля и стоит ли оно того. Сейчас в код SFX полноценный обработчик RAR'овских ключей не входит.

Всего записей: 1536 | Зарегистр. 29-04-2013 | Отправлено: 12:17 06-03-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
insorg
EugeneRoshal
 
Немного не точно. Давид Солмон (разработчик DEC OSF/1, Open VMS и Windows NT) когда-то нам в DEC объяснил как работает механизм сжатия в драйвере NTFS (NTFS.SYS) управляемый атрибутом "C" (Compressed):
 
1) Если у каталога в который пишется файл стоит атрибут С- ("не сжатый"), то файл пишется без компрессии в подходящие по размеру свободные участки тома, иначе если для файла установлен атрибут С+ перед его помещением в буфер записи в ОЗУ производится LZ77 сжатие.  
 
2) Если файл уже существует, то он считывается в ОЗУ, сжимается в буфере и передаётся в буфер записи.
 
3) Далее происходит запись в первый подходящий по размеру непрерывный свободный участок тома. Если его нет осуществляется фрагментация потока записи с предпочтением выбора близко расположенных кластеров.
 
При чтении драйвер проверяет состояние атрибута Compressed и если для файла его значение ON (С+), то при чтении файл помещается в промежуточный буфер в ОЗУ где происходит его декомпрессия, а после передаётся в буфер чтения ОС. Если атрибут compressed сброшен (С-) считанные данные сразу помещаются в буфер чтения.  
 
Для каталогов компрессия/декомпрессия не осуществляется и атрибут compressed используется для определения необходимости включения сжатия хранящихся в них файлов. Среднее сжатие тома NTFS может достигать ~ 1,4, но сжимать корневой каталог тома не рекомендуется т.к. это вызовет ошибки в определении скоростей чтения/записи на таком томе. Рекомендуется индивидуальное сжатие каталогов и содержащихся в них файлов при необходимости.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2667/C602J/16 GB REG ECC DDR3-1866/GTX 1660, i7-2600/z68/16 Gb DDR3-1600/GTX 1060 3Gb

Всего записей: 29434 | Зарегистр. 31-07-2002 | Отправлено: 14:25 06-03-2021
frost745

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Версия 6.01 бета 1 (рус.)
Подробнее...

Всего записей: 3953 | Зарегистр. 26-02-2013 | Отправлено: 14:42 06-03-2021
GoblinNN

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

Всего записей: 1982 | Зарегистр. 11-10-2005 | Отправлено: 15:58 06-03-2021 | Исправлено: GoblinNN, 16:08 06-03-2021
Victor_VG



Tracker Mod
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
GoblinNN
 
LZ77 не самый эффективный, но один из самых быстрых алгоритмов компрессии данных. Потому и применяется, в т.ч. в аппаратуре - например в стримерах (НМЛ) с аппаратным сжатием, таких как COMPAQ 9000 DDS-3 (HP StorageWorks DAT 24) стример, которые при подаче по шине команды осуществляют аппаратное сжатие записываемого потока для увеличения ёмкости носителя. Это также увеличивает и скорость записи т.к. физический объём записываемых данных уменьшается по сравнению с исходным, а при чтении устройство само осуществляет их декомпрессию.  
 
Но, расплатой за скорость и минимальные требования к вычислительной мощности процессора данного алгоритма является его не очень высокое сжатие зависящее от структуры входного бинарного потока.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2667/C602J/16 GB REG ECC DDR3-1866/GTX 1660, i7-2600/z68/16 Gb DDR3-1600/GTX 1060 3Gb

Всего записей: 29434 | Зарегистр. 31-07-2002 | Отправлено: 16:32 06-03-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

Компьютерный форум 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