» WinRAR (часть 2)

skipik

Ну а что ещё от них ждать? Знаете что делает кот когда ему делать нечего? Так и эти идиоты...

Victor_VG
Вчера в теме Emsisoft AM прочитал, там по поводу беты последней написано, что пока не выйдет финальная версия просят не запаковывать вирусные архивы архиватором . Вирусы не может увидеть практически ни один антивирус кроме G-DATA и AVAST , а основные не видят. Может поэтому и срабатывания ложные. Как финал выйдет всё успокоится.

Ссылка

slaileb

Да это и так понятно - в RAR5 иной формат контейнера, а переписывать мухобойки для его чтения кое-кому лень или просто демонстративно нет желания. Я не удивлюсь если позже эти люди для этого новый предлог найдут, и не обязательно им станет именно rar...

P.S.

К примеру у меня лично 90% архивов это тарбаллы и я тоже ворчу на то что порты демонёнка стали паковать не в bzip2 а в xz - пока мне это не привычно, да куды я денусь? Не стану же я перепаковывать в привычный мне bzip2 все 23718 пакеджей для AMD64 с сайта PC-BSD из коллекции портов 9.1-RELEASE. Их там под 47 Гб только в одном каталоге ./All наберётся, и это не считая что на них существует примерно втрое больше симлинков. У меня и другие дела найдутся, а с пакеджами и tar прекрасно разберётся.

EugeneRoshal

Установил таки себе WinRar-5-b7.
Обнаружил такой глюк, что при уже запущеной программе, невозможно открыть архив, находящийся не в папке запуска.

Обойти глюк удалось командой Ctrl+D

Inoz2000

Цитата:

Установил таки себе WinRar-5-b7.
Обнаружил такой глюк, что при уже запущеной программе, невозможно открыть архив, находящийся не в папке запуска.

Обойти глюк удалось командой Ctrl+D

Достаточно включить показ дерева каталогов. Ctrl+T спасёт отцов русской демократии.

Inoz2000 22:23 24-07-2013
Цитата:

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

А какая ось? На XP не наблюдаю такого (или суть глюка не понял).

по порядку
с деревом у меня всё нормально (включены обое галочки). и оно тут ни при чём.
на той же оси w764u такое не происходило ниразу с версией 4.20
суть глюка:
вариант I
- из проводника открыть к.-либо архив
- из другой папки открыть другой архив даёт ошибку

вариант II
- открыть winrar.exe из его папки в %ProgramFiles%
- Меню Файл -> Открыть архив (какой нибудь)
- Меню Файл -> Открыть архив (какой нибудь) даёт ошибку

А если перед открытием архива воспользоваться командой Ctrl+D, то открывает

Inoz2000 23:26 24-07-2013
Цитата:

суть глюка:

В обоих вариантах попробовал - всё нормально. Билд 50b7 от 23.07.2013.

Inoz2000

И у себя с момента выхода 7-й беты такого не видел. Предполагаю что причины имеют внешнюю по отношению к Rar природу.

Цитата:

всё нормально. Билд 50b7 от 23.07.2013.

Спасибо за подсказку
Была у меня версия от 13.07 (русская)
Сейчас я скачал с датой 24.07, и все заработало!
Ну не ожидал я такого подвоха

И ещё хотел сказать,

Открытый архив свободно можно удалить/переименовать, но WinRar на это никак не реагирует. И дальше при получении фокуса, как ни в чём ни бывало, позволяет пользователю мирно путешествовать по папкам уже несуществующего архива.

Этот недостаток есть и у предыдущей версии

Добавлено:
Victor_VG
addhaloka
если не верите, скачайте её (шютка )

Inoz2000

Это не новость. Многие программы так работают. Такой приём позволяет снизить нагрузку на систему и избежать лишних конфликтов ПО.

Victor_VG
Я имею в виду, что не плохо было бы сделать проверку лишь при получении программой фокуса (так делает AkelPad, если я правильно понял). Это не создаст нагрузку на систему, а польза кое-какая будет, имхо.

Добавлено:


А я уже боюсь спрашивать, это только у меня при обновлении непрерывного архива всего лишь одним изменённым файлом происходит Ошибка контрольной суммы BLAKE2?

Добавлено:

Цитата:

Наиболее заметный прирост производительности многопоточность даёт при извлечении крупных файлов с плохо сжимаемыми данными или при использовании контрольных сумм BLAKE2.

Захотел прироста производительности… , а не тута было

Inoz2000

Проверил ваши наблюдения. Взял пару файлов по 50 М из тех кого не сжать к одному в хвост приписал пяток байт нулей, формат rar5, добавление из GUI и консоли, solid, -rr3% - сообщений об ошибке у меня не было. Значит либо я не смог воспроизвести ваш эксперимент, либо ошибка у вас возникает по иной причине...

Victor_VG
Или Вы нарочно не упомянули о галочке использования BLAKE2 в GUI (ключ -htb в консоли) или у меня в компьютере (в голове?) творится какая-то мистика. пока умолкаю

Inoz2000

Перепроверил - у меня ошибка не воспроизводится на трёх разных машинах, опция стоит, что с ключом, что без, сборка от 24.07.2013 13:31:00,00 x86 En-US... ЧЯНДТ?

Методику обновления локализованной сборки я приводил ранее, могу только посоветовать во избежания блокировки RarShell.dll распаковывать дистрибутив к примеру 7-Zip 9.30 Alpha - распакует и проблемы блокировки не возникнет. Сам так обновляюсь раскидывая обновления по тестовой сети в 7-Zip архивах.

Inoz2000 00:24 25-07-2013
Цитата:

А я уже боюсь спрашивать, это только у меня при обновлении непрерывного архива всего лишь одним изменённым файлом происходит Ошибка контрольной суммы BLAKE2?

То же самое, подтверждаю.

addhaloka

А сборка какая? Может более ранняя чем та на какой я проверял и эта ошибка уже в прошлом?

Victor_VG 08:02 25-07-2013
Цитата:

А сборка какая?

Последняя, какая же ещё.


Добавлено:
SAT31 12:12 25-07-2013
Цитата:

Да тут сборка беты 7 постоянно обновляется тихо.

Про это тоже известно.

Да тут сборка беты 7 постоянно обновляется тихо.
http://i066.radikal.ru/1307/6e/635b0a15dda3.png

Inoz2000

Цитата:

А я уже боюсь спрашивать, это только у меня при обновлении непрерывного архива всего лишь одним изменённым файлом происходит Ошибка контрольной суммы BLAKE2?

У меня тоже. Буду разбираться, спасибо. Причем, в beta 2 это еще работало, а в beta 3 и последующих поломалось. Это к вопросу, почему после смены формата надо бета-тестироваться не меньше 3 - 4 месяцев.


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

Ради выравнивания заменил в структуре - контексте blake2 массивы на указатели, а написать конструктор копирования и оператор присваивания забыл. Вот и вылезло.

Опять происходит конфликт параметров сжатия в реестре.
так получилось, что новая версия опять не дружит со старой (ну сколько можно!), параметр PackDetails такой загадачный, что при архивации через GUI включение/выключение галочки Алгоритм сжатия 32-разрядных исполняемых файлов (Pentium) никак не влияет на результат.
Придётся вписывать этот PackDetails в моих профилях архивации вручную. а чё делать?

ps А что это я панику поднимаю, галочка в GUI выключена, а сжатие-то и так всё равно срабатывает

Добавлено:
EugeneRoshal

Зачем было менять размер параметра PackDetails, ведь ничего не добавлено и не убрано?
я не понял

Inoz2000
Поправил, теперь должно быть совместимо по этому параметру с 4.20. Перевыложил.

Если вы уже отредактировали настройки этих фильтров, к сожалению, придется редактировать их опять. Но тут важнее совместимость с 4.20, а не предыдущими бетами.

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

behar

Где-то больше недели назад наблюдал проблемы с падением Explorer на Win7 x64 SP1 (НЕ вирус, абсолютно точно) - причём не только в случае использования WinRAR. После того, как пришли плановые обновления для системы, проблемы исчезли. Так что, вероятно, проблема не связана с WinRAR. Попробуйте обновить ОС.

behar
Не помню, чтобы я что-то подобное недавно исправлял. Сейчас проверил с отменой распаковки RAR архива - не упало. У вас падает 5.0 beta 7 или какая-то предыдущая версия?

EugeneRoshal
У меня вот уже года 2, как стоит win7x64 и все это время WinRar ложит эксплорер при распаковке через drug&drop. Версии само-собой обновлялись.

Извиняюсь, при прирывании сейчас проходит нормально. Стабильно падает при drug&drop -> ввод пароля -> ввести неверный пароль.
ошибка:
[more]
Имя события проблемы:    BEX64
Имя приложения:    explorer.exe
Версия приложения:    6.1.7601.17514
Отметка времени приложения:    4ce7a144
Имя модуля с ошибкой:    MSVCR80.dll
Версия модуля с ошибкой:    8.0.50727.6195
Отметка времени модуля с ошибкой:    4dcdd833
Смещение исключения:    000000000001df0d
Код исключения:    c000000d
Данные исключения:    0000000000000000
Версия ОС:    6.1.7601.2.1.0.256.1
Код языка:    1049
Дополнительные сведения 1:    40bd
Дополнительные сведения 2:    40bd8ad480a6f915fdbafd00c0666870
Дополнительные сведения 3:    81a0
Дополнительные сведения 4:    81a00d8dbe1ff1a3af4f47344b8c0b85
[/more]

behar
Проверил с неверным паролем, все равно не падает. Но я посмотрел в отладчике, при неправильном пароле WinRAR'овский IDataObject::GetData возвращает E_ABORT, который в официальном списке возможных результатов этого метода отсутствует. Так что я сейчас заменил код возврата в этой ситуации на E_UNEXPECTED и выложил новую сборку английской beta 7 на rarlab.com. Проверьте, пожалуйста, повлияло ли это на наблюдаемую вами проблему.

Цитата:

выложил новую сборку английской beta 7 на rarlab.com. Проверьте, пожалуйста, повлияло ли это на наблюдаемую вами проблему.

К сожалению, не помогло. Упал с тойже ошибкой.

behar
Тогда не знаю, в чем тут дело. У меня не падает, у других пользователей, вроде бы, тоже. Может какое-то другое shell extension влияет. Это надо crash dump в отладчике смотреть.

behar

Цитата:

К сожалению, не помогло. Упал с тойже ошибкой.

Падает, судя по логу, не Winrar, а Explorer где-то в глубине msvcr80.dll.

Как вариант: отключить все сторонние shell extensions, возвращать их по одному и смотреть - после какого начинаются падения. Это можно сделать, к примеру, бесплатной программой ShellExView от NirSoft или любой аналогичной утилитой.