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

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

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

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)
 
Список изменений на английском языке
(на родном – смотрите файл 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)

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

Всего записей: 37394 | Зарегистр. 26-02-2002 | Отправлено: 19:30 27-08-2020 | Исправлено: Inoz2000, 22:53 31-08-2021
EugeneRoshal

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

Цитата:
похоже, надо сделать счётчик для M после H. До двух M подряд (разделить любой символ) считаются минутами, а последующие обозначением месяца.

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

Цитата:
Тогда HH_M_M не будет возвращать разбитое число минут

Так он должен возвращать разбитое число минут, почему нет.

Цитата:
а несколько MMMMMMMM не будут интерпретироваться несколько раз.

В общем случае такие последовательности не интерпретируются несколько раз. Можете проверить с YYYYYYY или HHHHHHH. MMM это единственное исключение. Обработка символьных названий месяцев отличается от обработки остальных полей времени, и там такая проверка не работала. Сейчас сделал, будет работать и для MMMMMMMM.

Цитата:
Если кто-то вдруг захочет использовать 7Jul, то в текущей реализации не сможет.

Я сознательно ограничиваю возможность повторного указания того же поля времени в маске, вместо того, чтобы начать выводить его заново. Маски типа MMMM или YYYYY это практически всегда опечатка пользователя, а не какой-то хитрый замысел, и лучше дать эту опечатку заметить. Если увижу, что в реальных задачах пользователям действительно требуется указать месяц в маске дважды, в символьном виде, и как число, можно будет рассмотреть возможность реализации. Но пока я с такими задачами не встречался. Предположу, что на практике это нужно примерно так же, как МИНУТЫМИНУТЫ или JulJulMM.

Цитата:
или вообще число дня в середине числа месяца
-agM{"текст"}aM{"текст"}
0текст57текст  

07 это месяц, 5 это номер дня недели. Как просили.
 
Добавлено:
AlexDAT

Цитата:
похоже, надо сделать счётчик для M после H. До двух M подряд (разделить любой символ) считаются минутами, а последующие обозначением месяца.

Хотя если вспомнить про американский вариант даты, с месяцем перед днем, тогда, пожалуй, вы правы насчет варианта со счетчиком. Что-то типа: HH-MM-MM-DD-YY. Только первые два M после H должны быть минутами.
 
Не уверен, правда, про "подряд". Надо ли запрещать разделители между первыми двумя M. Имеет ли право на существование какой-нибудь вычурный h.h.m.m, и что мы выигрываем, запрещая такие варианты и обрабатывая в этой маске второй M как месяц.

Всего записей: 1485 | Зарегистр. 29-04-2013 | Отправлено: 15:04 09-07-2021 | Исправлено: EugeneRoshal, 16:52 09-07-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AlexDAT
Правда можно придумать маску только с часами без минут и американской датой: HHMMDDYY. Тут уже не угадать, минуты это или месяц. Только часы и обычная дата HHDDMMYY тоже может создать проблемы, если использовать только счетчик M после H и не сбрасывать его по D. Но на практике вряд ли применяются варианты только с часами, да еще и впереди даты.

Всего записей: 1485 | Зарегистр. 29-04-2013 | Отправлено: 17:45 09-07-2021
AlexDAT



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal сам не пользуюсь, но больше беспокоит, что даже принудительное разделение текстом {} и другой переменной не прерывает шаблон. Вот кому может понадобится разбивать число месяца числом недели, как я привёл пример?
Если кто-то слепит без разделителя минуты и месяцы, то сам себе буратино. Другое дело, если есть разделитель. Например, делает бекапы в разное время суток (отслеживает правильность выполнения задачи по времени в имени архива), но не более N количества раз в месяце. Тогда может быть указано время создания бекапа и месяц, а дата второстепенна. Конечно, это теоретический вариант.

Всего записей: 2315 | Зарегистр. 21-04-2009 | Отправлено: 17:55 09-07-2021
GoblinNN

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal, регистрозависимыми сделать их mm - минуты MM - месяц

Всего записей: 1889 | Зарегистр. 11-10-2005 | Отправлено: 18:10 09-07-2021 | Исправлено: GoblinNN, 18:10 09-07-2021
AngelNet



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
подскажите пожалуйста, а можно винрар заставить выводить полное имя текущего месяца, а не только три буквы?
например: Jul > July
                Июл > Июль
(неважно какое количество символов в имени месяца, для локализованных версий.)
спасибо!

----------
animelist

Всего записей: 6741 | Зарегистр. 11-03-2004 | Отправлено: 18:19 09-07-2021 | Исправлено: AngelNet, 18:20 09-07-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Я, как и AlexDAT, скептически отношусь к вставке постороннего текста между разрядами числа в дате/времени. Так что, если Вы оцениваете востребованность пользователями, я голосую за неразрывность полей: варианты типа h.h предлагаю считать невалидными (возможно, начиная с 7-й версии, чтобы обеспечить обратную совместимость). Тем самым упростится код вывода. Как вариант, одиночную букву можно трактовать как число без ведущих нулей.
 
GoblinNN
Я бы голосовал за эту идею, но, как я понял, WinRAR принципиально не различает регистр в ключах, как это принято ещё со времён MS-DOS. Правда, в Rar.txt это в явном виде не написано - только в winrar.chm.
 
AngelNet
Судя по всему, нельзя. А если бы было можно, как склонять месяц? Скажем, сегодня я хочу "архив_от_09_июля_2021.rar", а завтра "архив_за_июль_2021.rar". Аналогично с AM/PM в часах.

Всего записей: 457 | Зарегистр. 12-06-2019 | Отправлено: 19:13 09-07-2021
EugeneRoshal

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

Цитата:
больше беспокоит, что даже принудительное разделение текстом {} и другой переменной не прерывает шаблон

Не хотелось бы усложнять синтаксис без необходимости. Если нынешнее поведение приведет к каким-то реальным затруднениям, тогда буду смотреть, но пока не жаловались.

Цитата:
Если кто-то слепит без разделителя минуты и месяцы, то сам себе буратино.

Если брать в качестве минут первые две M после часов, то и этот случай обработается нормально. Это только если часы и месяцы слепить, тогда проблема.
 
GoblinNN

Цитата:
регистрозависимыми сделать их mm - минуты MM - месяц

Смысл этих заморочек с позицией M - облегчить пользователям ввод шаблона. Так бы я мог назначить минуты и месяцы на разные буквы, но это еще вспомни что чему соответствует. Пришлось бы каждый раз лазить в документацию. С регистрозависимым вариантом, подозреваю, тоже придется заглядывать в документацию. Да и периодически люди будут путаться и указывать минуты или месяцы не в том регистре. Сейчас сложнее что-нибудь перепутать. Хоть yyddmmhhmm вводи, хоть YYDDMMHHMM.
 
AngelNet

Цитата:
подскажите пожалуйста, а можно винрар заставить выводить полное имя текущего месяца, а не только три буквы?

Разве что отредактировать имена месяцев в .lng файле. Но оно может повлиять на несколько функций, например, на лог-файлы.
 
Добавлено:
uShell

Цитата:
варианты типа h.h предлагаю считать невалидными (возможно, начиная с 7-й версии, чтобы обеспечить обратную совместимость). Тем самым упростится код вывода.

Упростится вряд ли, скорее даже усложнится. Сейчас разделители разрешены везде, а придется разрешать их только между полями. Причем, непонятно, что мы выиграем от такого изменения.

Всего записей: 1485 | Зарегистр. 29-04-2013 | Отправлено: 19:18 09-07-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Насчёт усложнения соглашусь - я не учёл, что надо обрабатывать корректность строки. Я подумал, что при запрете разбиения ускорится обработка: если видим HH, то сразу пишем сюда часы через sprintf, тогда как для H.H после первой H надо записать hours%10+'0', а потом ещё сканировать всю форматную строку на предмет продолжения.
 
Вот так можно было бы написать код (неоптимизированный)

Всего записей: 457 | Зарегистр. 12-06-2019 | Отправлено: 19:58 09-07-2021
AngelNet



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uShell
да мне склонять не нужно) хватит и именительного падежа, дернутого из настроек виндовс!
 

Цитата:
Разве что отредактировать имена месяцев в .lng файле.

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

----------
animelist

Всего записей: 6741 | Зарегистр. 11-03-2004 | Отправлено: 20:22 09-07-2021
EugeneRoshal

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

Цитата:
если видим HH, то сразу пишем сюда часы через sprintf, тогда как для H.H после первой H надо записать hours%10+'0'

Я с помощью 10 sprintf готовлю char Field[10][6] со полными строками для 10 возможных модификаторов. Потом для текущего символа маски определяю номер модификатора, используя wcschr(L"YMDHISWAEN",*Mask), и беру для него очередной символ из массива Field. Если wcschr вернула NULL, это разделитель. Получается достаточно компактный код, который вещи типа YYYY и YY обрабатывает автоматически. Switch на 10 вариантов вероятно был бы более объемным.

Всего записей: 1485 | Зарегистр. 29-04-2013 | Отправлено: 21:37 09-07-2021
regist123



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal написал(а)
Цитата:
Смысл этих заморочек с позицией M - облегчить пользователям ввод шаблона. Так бы я мог назначить минуты и месяцы на разные буквы, но это еще вспомни что чему соответствует. Пришлось бы каждый раз лазить в документацию. С регистрозависимым вариантом, подозреваю, тоже придется заглядывать в документацию. Да и периодически люди будут путаться и указывать минуты или месяцы не в том регистре. Сейчас сложнее что-нибудь перепутать. Хоть yyddmmhhmm вводи, хоть YYDDMMHHMM.

Всё-таки также поддержку предложение сделать регистрозависимыми.
1) Это привычное поведение которое часто используется и в других местах, а поэтому как раз такое написание интуитивно (если человек привык писать форматы масок времени). К примеру даже если взять википедию https://ru.wikipedia.org/wiki/ISO_8601 то там тоже используется этот принцип.
2) Если человек не знает как правильно писать и путается, то просто обязан посмотреть документацию как писать правильно. Так что аргумент, что придётся смотреть документацию мне кажется не уместным.

----------
Раздачи и акции

Всего записей: 6799 | Зарегистр. 20-03-2009 | Отправлено: 14:19 11-07-2021
EugeneRoshal

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
regist123
Сложность в том, что эта функция не реализуется сейчас с нуля, а давно присутствует в RAR. У пользователей есть уже и наработанные привычки, и командные файлы. Чтобы создать проблемы с совместимостью, нужна какая-то серьезная причина и выигрыш. А мы тут выигрываем только возможность указать часы без минут со следующим за ними месяцем. Что-то типа -aghhmmddyy.

Всего записей: 1485 | Зарегистр. 29-04-2013 | Отправлено: 15:23 11-07-2021
justmann

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
 
 
Беру 20 файлов размером 350 МБ одинакового содержания, но с разными именами. Замечательная идея создать непрерывный архив, ведь файлы одинаковые и ожидаемый размер архива должен получиться равным размеру 1 архива + пару килобайт на запись других имен.
 
Но!!! Винрар абсолютно не справился с задачей, создав многогигабайтный архив! Неужели сложно внедрить функцию подсчета хеша и если хеши одинаковые - то содержимое файлов считать одинаковым и при упаковке solid-архива паковать только имена файлов.

Всего записей: 67 | Зарегистр. 08-06-2021 | Отправлено: 13:04 13-07-2021
Sish



Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann
Согласитесь, уважаемый, что ситуация, подобная описанной Вами, едва ли встретится в реальной практике.

Всего записей: 25264 | Зарегистр. 09-06-2004 | Отправлено: 13:13 13-07-2021
AlexDAT



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann может не так архивировали или всё же содержимое отличалось?
Сейчас проверил и вполне из 7 одинаковых файлов (копии) по 15,4 МБ получил архив весом 15,4 МБ.
Сохранять идентичные файлы как ссылки

Всего записей: 2315 | Зарегистр. 21-04-2009 | Отправлено: 13:21 13-07-2021
Gnomi

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

Цитата:
Беру 20 файлов размером 350 МБ одинакового содержания, но с разными именами.  

 
Если бы размер словаря для упаковки был бы не менее 350*20=7000 мб, а все требуемые файлы при архивации одномоментно влезли бы в этот словарь, ваша задача была бы решена.
 
В общем виде, это задача называется "дедупликация", в корпоративных системах хранения для её решения применяются серверы баз данных.

Всего записей: 33 | Зарегистр. 24-12-2005 | Отправлено: 13:36 13-07-2021 | Исправлено: Gnomi, 13:38 13-07-2021
justmann

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Всё завязано под размер словаря. Одинаковые мелкие файлы он пакует в непрерывный архив, но вот файлы по 350 МБ - он не способен признать одинаковыми!
 
Неужели за столько лет развития архиватора, никто не предложил добавить функцию - сравниваем размер файлов, если размер одинаковый вычисляем MD5 хеш - если хеш одинаковый - значит файлы одинаковые и их нужно утаптывать в SOLID-архиве как один файл. Неужели за овер 30 лет и овер 100 версий не появилась такая примитивная проверка. Ведь для вычисления хеша не нужно огромные ресурсы, словари и прочее....

Всего записей: 67 | Зарегистр. 08-06-2021 | Отправлено: 14:52 13-07-2021
AlexDAT



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann ощущение, что не читаете ответы. Такая упаковка реализована отдельной опцией.

Всего записей: 2315 | Зарегистр. 21-04-2009 | Отправлено: 15:19 13-07-2021
uShell

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
justmann
Как я понял, Вы хотите, чтобы WinRAR автоматически сортировал файлы и помещал одинаковые как можно ближе друг к другу. Тогда, если размер словаря превосходит размер файла, дубликаты будут упакованы с приличным сжатием. Я бы поддержал такое предложение: и сортировка, и сравнение в WinRAR уже есть - остаётся их "подружить". Но надо будет подумать, как этот режим будет сочетаться с сортировкой по расширению.
 
В Вашем случае, если включить solid-сжатие и задать размер словаря хотя бы 512 МБ (при условии, что одинаковые файлы имеют одинаковое расширение), архив не будет многогигабайтным. Проверьте.
 
И насчёт MD5 - за ним водятся ложноположительные срабатывания, поэтому для определения идентичности файлов его использовать не следует. Если дело только в сортировке, то можно и MD5 - при коллизии мы разве что потеряем сжатие, а вот с ключом -oi будет беда.

Всего записей: 457 | Зарегистр. 12-06-2019 | Отправлено: 18:49 13-07-2021 | Исправлено: uShell, 18:53 13-07-2021
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Дедупликация - интересная тема. Хотя это опять неизбежно привело бы к изменению формата RAR. Стоит ли овчинка выделки в 2021 году - большой вопрос.
 

Цитата:
И насчёт MD5

В WinRAR уже есть Blake2, который устойчив к коллизиям + быстрее, чем MD5.
 

Всего записей: 6643 | Зарегистр. 01-10-2002 | Отправлено: 19:32 13-07-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

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