» WinRAR (часть 2)

BFDA
Максимально, для длительного хранения, годится обычный solid. Для частого обновления solid разумнее выключить совсем. А полу-solid, о котором шла речь выше, это промежуточный вариант. Он не для максимального сжатия.

EugeneRoshal

Цитата:

Максимально, для длительного хранения, годится обычный solid.

Я пришел к совершенно обратному выводу. Для надежного длительного хранения не использовать solid совсем.

Цитата:

Для надежного длительного хранения не использовать solid совсем

Я тоже давно пришёл к такому выводу. Для надёжности - только не solid, пусть и объём побольше будет - эта мысль была в основе, когда ещё "и трава была зеленее, и небо голубее", а уж теперь, когда с местом для хранения данных не так критично...

V0lt

Цитата:

Для надежного длительного хранения не использовать solid совсем.

Так я и не спорю Просто выше в условии было сказано - "сжать максимально". Если же нужна максимальная надежность, а сжатие на втором месте, solid, как правило, лучше выключить, а recovery record включить.

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

Цитата:

Просто выше в условии было сказано - "сжать максимально".

я вообще то про solid-блочную технологию писал...

Не мог ли бы кто-то из компетентных форумчан подсказать - как средствами WinRAR добиться автоматической генерации отчёта (и его сохранения в заранее определённой папке) по каждому вновь создаваемому архиву?

Kate_rina
Сабж такого не умеет. Он только отчет об ошибках ведет - один на всех.
А какая информация тебе в отчете нужна? Список файлов можно сгенерировать предварительно, данные о режиме архивации получать из ключей командной строки, если архивацию командной строкой делать.
Вот ХЗ как код возврата по окончании операции (о статусе операции - нормально прошла или с косяками) выдать юзеру на глаза средствами WinRAR, но другой софт его нормально от WinRAR получает.

lucky_Luk

Задача стоит такая: максимально неявно для юзера, создающего rar-архивы в течении рабочего дня, генерировать отчёт по каждому из этих архивов (достаточно списка архивируемых файлов, с временем создания архива и с названием архива) для последующей отсылки этих отчетов на заранее определённый e-mail...

(программу для автоматической отсылки таких HTML-отчётов нашла вроде бы: 'ADirToMail v0.7.4.4')

Цитата:

Список файлов можно сгенерировать предварительно

только вручную?

А какой-нибудь сторонний софт прикрутить к WinRAR-у нельзя? (именно для этой задачи)

типа кейлоггер…?

Kate_rina

Это конечно можно сделать, но если узнают про ваше любопытство будет скандал. Освободитесь лучше стандартными средствами журналирования ОС по линии аудита событий.

Victor_VG
то и оно, что начальница за своими велит шпионить... А отчёты сама собирается читать. Скандала не будет...
За подсказку про аудит отдельное спасибо!

Inoz2000
думала уже про такое... Но там много лишнего... Да и антивирус не обрадуется...
Хотя посмотрю ещё (когда-то приятное впечатление оставил 'Perfect Keylogger v1.7.5.0')

Извиняюсь, что вопрос тут подняла этот... Думала, что просто не знаю скрытых возможностей WinRAR по созданию отчётов. Ан нет - это, похоже, абсолютно невостребованная в архиваторе функция... (хотя её реализация не представляется сложной. Но я дилетант, конечно, в таком)

Kate_rina

Вот коли лично ей это грязное дело надо, то пусть сама и покупает себе шапку-невидимку, бронежилет до пяток и сверхсветовую ступу для быстроты дёру и далее вперёд с песней. Ибо коли энто дело всплывёт, а оно всплывёт обязательно, она в стороне, а вы будете виноваты во всех смертных грехах, и меж двух огней окажитесь, так что тогда я вам не завидую - стукачей нигде не любят. Посему смотрите сами - либо сразу работу искать, либо умно сыграть Хаджу Насреддина - "За десять лет кто-то один из нас обязательно умрёт - либо осёл, либо шах, либо я..."....

Короче я предупредил - "Мины!", а вам решать лезть на них али нет.

Kate_rina


Цитата:

то и оно, что начальница за своими велит шпионить... А отчёты сама собирается читать.

Странная задача. Важно не ЧТО упаковывается в архив, а куда потом девается этот архив.
Замучаешься следить. Плохиш может не только подсовывать конфиденциальную инфу в архив вместе с нормальной инфой, а и сначала создать "нормальный" архив, а потом подпаковать туда конфиденциальные файлы.
Понадобится фиговина, которой заменяем WinRAR.exe и он перехватывает и логгирует все, что система посылает к WinRAR.exe, а потом вызывает нормальный WinRAR.exe. Но например тупое перетаскивание файла в окно WinRAR с открытым архивом так не перехватишь.
Короче, пусть начальница либо нанимает специально обученную обезьяну (вариант - подключает СБ вашей конторы) - или не изображает видимость активной деятельности.
Такую фигню инсайдер обойдет после первого же прокола, а возни много с ней. Точка для слежки неверно выбрана, ИМХО. Пахнет то ли тупорылыми кознями бабьими со стороны начальницы, то ли паранойей, то ли ее желанием выслужиться перед вышестоящим начальством.

Спасибо за поддержку, ребята...

Я и правда не стукач...

Уже отбрехалась от этого "поручения"... почти как Насреддин...

всех с Новым годом и Рождеством!

Подскажите, как в командной строке получить максимально полный аналог команды "Создать отчёт" в WinRar ?
"rar.exe l архив" и rar.exe v архив" очень сильно не дотягивают по функционалу команде "Создать отчёт", т.к. мне нужно получить отчёт для:
- архивов zip ;
- ВСЕХ файлов в папке (аналог команды "Создать отчёт" WinRar в режиме управления файлами).

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

Может, немного дополнить формат RAR возможностью сохранять blake2sp не в виде своих 256-бит, а покороче? 256 бит - не слишком ли дофига?

Можно взять первые 128 бит от blake2sp, либо еше установить байт корня в 0x10...

Цитата:

Может, немного дополнить формат RAR возможностью сохранять blake2sp не в виде своих 256-бит, а покороче? 256 бит - не слишком ли дофига?

А какой тогда смысл в blake2sp?

А что, 128 бит от блейка можно подогнать? Или схватить коллизию?
128 бит такая же стена.

persicum

Скорее можно получить эффект уменьшения корректирующей способности похожий на тот, когда сокращают код Хемминга (упрощенное описание). Код 16/22 позволяет править трёхкратные ошибки в 16-битном блоке, но код 7/12 сделает то же для 7-и битного блока, код 72/76 имеющий меньшую избыточность имеет и большее кодовое расстояние - 4 вместо трёх и правит четырёхкратные ошибки а не трёх кратные как коды 7/12 и 16/22.

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

Для исправления ошибок winRAR использует 16-битные коды РидаСоломона, исправляющие ошибки кратностью до 65535.

А блейк - это всего лишь контрольная сумма, ничего она не лечит. Ее задача - ответить на вопрос, изменялись данные или нет.

persicum

Цитата:

Для исправления ошибок winRAR использует 16-битные коды РидаСоломона, исправляющие ошибки кратностью до 65535.

Достаточно, не вижу смысла продолжать "беседу" - не интересно.

Victor_VG
Думаю, автор RSC32 разбирается в кодах РидаСоломона лучше.

Что касается 256-битных хешей в архиве, это по-моему абсолютно бессмысленно. В теме по RSC32 я уже писал, что и простого CRC64 для целей контроля целостности достаточно. Хотя согласен, что компромиссом между здравым смыслом и параноей тут мог бы стать какой-нибудь быстрый 128-битный криптографический хеш.

Цитата:

быстрый 128-битный криптографический хеш.

По стандарту, blake может выдавать хэш любой длины, если ее положить в первый байт инициализации. Скажем, вместо 32 положить 16, и вот он уже короткий быстрый хеш.

Насчет блейк2sp не уверен, может в корневой проход тоже можно указать число 16 вместо 32, и все.

Victor_VG
Никто вас за язык не тянул, это вы сами понаписали галиматьи.


Цитата:

простого CRC64 для целей контроля целостности достаточно

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

Ajaja

Цитата:

Что касается 256-битных хешей в архиве, это по-моему абсолютно бессмысленно. В теме по RSC32 я уже писал, что и простого CRC64 для целей контроля целостности достаточно.

Есть класс ошибок, которые CRC не видит. CRC с начальным 0 в сдвиговом регистре игнорирует нули в начале данных. Их можно удалять и вставлять - результат будет одинаков. Если мы, как это принято, инициализируем регистр единицами, ситуация чуть усложняется: если первые 4 байта данных 0xff - после них можно вставить или удалить любое количество 0, CRC это не заметит. Да, маловероятная ошибка, но я бы не сказал, что абсолютно невозможная.

Цитата:

компромиссом между здравым смыслом и параноей тут мог бы стать какой-нибудь быстрый 128-битный криптографический хеш

BLAKE2sp и есть быстрый криптографический хэш. Примерно 2 GB/s на i7-2600. Для SHA2-256 на основе интеловских исходников с использованием AVX1 на этом же железе я получил 300 MB/s. Правда Intel SHA extensions могут изменить ситуацию, но их еще нужно дождаться.

persicum

Цитата:

256 бит - не слишком ли дофига?

Разница с 128 битами - 16 байт на файл. Реально заметим только на россыпи очень маленьких файлов. А полноценный 256-битный хэш может использоваться не только для обнаружения ошибок, но и для сравнения файлов в архиве на глаз без распаковки. Если полный BLAKE2sp хэш совпал, значит файлы одинаковые. Для 128 бит BLAKE2 без соответствующего анализа укороченного варианта специалистами такой уверенности нет, особенно при наличии умысла на подделку хэша. 128-битный MD5 подделывается вполне успешно. Кроме того, просто хотелось стандартности. Я надеялся, что BLAKE2sp будет использоваться в каком-нибудь еще софте, но пока с этим дела обстоят не очень и теперь, с учетом планов Intel по SHA extensions, вряд ли улучшатся.

EugeneRoshal
Спасибо за развернутый ответ, особенно приятно это слышать от человека-легенды.


Цитата:

Для 128 бит BLAKE2 без соответствующего анализа укороченного варианта специалистами такой уверенности нет, особенно при наличии умысла на подделку хэша

Блейк-128 вполне себе полный хеш, внутренне 32-байтный. Только укорачивается вывод, берутся первые 16-байт результата.

Плюс начальное наполнение там не 20......20.., а 10........20... Вторая 0x20 указывает, что внутри он полноценный.

Просто я подумал, чтобы блейк успешно вытеснил md5 и sha1 в околоварезном общении, короткий блейк был бы лучше длинного. С длинным хэшом не удобно обращаться. Но для этого нужно популяризировать как сам блейк-256, так и блейк-128.

persicum

Цитата:

Просто я подумал, чтобы блейк успешно вытеснил md5 и sha1 в околоварезном общении, короткий блейк был бы лучше длинного. С длинным хэшом не удобно обращаться. Но для этого нужно популяризировать как сам блейк-256, так и блейк-128.

На мой взгляд, для этого им надо было в штатной b2sum режимом по умолчанию ставить blake2sp, а не blake2b. Причем, остальные режимы хорошо спрятать, чтобы они не вносили путаницы, для популяризации важна стандартность. blake2sp - потому что однопоточные режимы в разы медленнее на многоядерных cpu, а 512-битный blake2bp, во-первых, слишком длинный, и, во-вторых, медленнее на 32-битных платформах. Может со скоростью blake2bp на 32 битах что-нибудь и можно сделать, но 512 бит для массового использования это перебор, а считать 512 и использовать только 256 мне эстетически не нравится

Я эти соображения писал разработчикам BLAKE2 еще прошлой весной. Мне ответили, что они тоже думали на эту тему, но предпочли BLAKE2b в качестве умолчания за простоту и скорость, а будущее покажет.

Добавлено:
persicum
А насчет того, что 256 бит многовато, так сейчас много где выкладывают sha256 хэши файлов. Хэш, конечно, длинный, но по моим ощущениям еще на верхней границе приемлемости. Вот 512 бит, это уже не для людей, а для машин, взглядом окинуть сложно.

Версия 4.хх не открывает архивы созданные 5-ой версией?

veljeys 20:47 02-01-2014
Цитата:

Какие преимущества у HaoZip перед Winrar'ом, кроме бесплатности HaoZip, ведь Winrar по сути тоже бесплатен... Стоит ли переходить на HaoZip?

veljeys взяли бы и спросили это в теме про HaoZip или у тех, кто на него перешёл. Почему вы думаете, что тут вообще есть пользовали HaoZip.

veljeys

Таких проблем не было. Прочтите Whatsnew.txt, пункт 1 списка изменений для версии 5.0.

Цитата:

взяли бы и спросили это в теме или у тех, кто на него перешёл. Почему вы думаете, что тут вообще есть пользовали HaoZip.

Ага, там и спрошу, благодарю за ОЧЕНЬ умный совет.