» WinRAR (часть 2)

SAT31

А то, что ЛЮБОЙ ТАРБАЛЛ ПО ОПРЕДЕЛЕНИЮ ЭТО ДВОЙНОЙ АРХИВ - внутри внешнего архива находится архив tar (сжатие 1:1 - это особенность tar - он сам не имеет функций компрессии, но он умеет вызывать внешние компрессоры) содержащий точную копию фрагмента файловой системы. Двойной архив разных форматов - это вам ничего не говорит? Хотя, судя по всему вы просто не представляете себе с чем столкнулись и упрямо пытаетесь запустить вине под виндой. Ну, ну, это говорят иногда полезно - шишки набивать. За одного битого двух небитых дают /А.В. Суворов/.

Victor_VG

Цитата:

и упрямо пытаетесь запустить вине под виндой

где я писал про такое?
EugeneRoshal

Цитата:

Первые несколько секунд, пока читается содержимое архива, список файлов пуст

точно, во ступил, счетчик файлов прошел и все отобразилось. Спасибо.

SAT31

А кто сказал дистрибутив? А под UNIX это лишнее - chwd wine&&make install clean - и она сама с тарбаллом разберётся.

Victor_VG
мне нужно было извлечь из архива файлы, все.

Victor_VG

Цитата:

А то, что ЛЮБОЙ ТАРБАЛЛ ПО ОПРЕДЕЛЕНИЮ ЭТО ДВОЙНОЙ АРХИВ - внутри внешнего архива находится архив tar (сжатие 1:1 - это особенность tar - он сам не имеет функций компрессии, но он умеет вызывать внешние компрессоры) содержащий точную копию фрагмента файловой системы. Двойной архив разных форматов - это вам ничего не говорит?

Не совсем так. Если вернуться к истокам понятий "архиватор" и "упаковщик" , то tar - архиватор, gzip/bzip2 и пр. - это упаковщики. Rar/zip/arj и пр. - это просто два-в-одном, и архиваторы и упаковщики одновременно. Сейчас в Windows все смешалось, но *nix-ы продолжают исповедовать принцип, когда одна утилита делает только одно дело, но делает это очень хорошо. Tar качественно архивирует файлы (в файл/на ленту/на диск/пр.), другая утилита качественно сжимает файлы (и не важно tar это или txt).

Ajaja

Цитата:

Если вернуться к истокам понятий "архиватор"  и "упаковщик" , то tar - архиватор, gzip/bzip2 и пр. - это упаковщики. Rar/zip/arj и пр. - это просто два-в-одном,  и архиваторы и упаковщики одновременно. Сейчас в Windows все смешалось

Смешалось оно гораздо раньше

Изначально под DOS все было точно так же, поскольку идеология перекочевала с *nix'ов. Была утилита LU (Library Utility), выполнявшая те же функции, которые сейчас выполняет tar, и создававшая так называемый библиотечный файл LBR. И были утилиты SQ и UnSQ (Squeeze и Unsqueeze), которые, соответственно, сжимали и разжимали любой отдельно взятый файл. Например LBR. Т.е. всё выглядело точно так же, как сейчас с tar+gzip/bzip2/xzip.

Но в 1985 году появилась утилита ARC, которая умела и "складывать" файлы в один, и сжимать их при этом. Так и появились на PC классические консольные архиваторы. Формат команд у них точно такой же, как у был у ARC почти 30 лет назад.

Но при этом WinRAR открывает .tar.bz2 "сразу". Т.е. при двойном клике мы видим уже список файлов внутри .tar
А, по логике, при открытии, например wine.tar.bz2 внутри должен показываться wine.tar, при клике по которому он открывается и мы видим файлы внутри него. Например, 7-zip поступает именно так.
Я придираюсь, конечно

Ajaja

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

Dart Raiden

Кстати, в данном случае (тарбаллы) поведение 7-Zip хотя для кого-то менее удобное, но точно соответствует сути - "внутри архива вложенный контейнер, потому сначала покажем его". Rar в данном случае копирует поведение команды tar -tf который в таких случаях самостоятельно вызывает необходимый внешний декомпрессор перед считыванием оглавления вложенного контейнера.

Dart Raiden

Цитата:

А, по логике, при открытии, например wine.tar.bz2 внутри должен  показываться wine.tar, при клике по которому он открывается и мы видим файлы внутри него. Например, 7-zip поступает именно так

именно с этим я и затормозил, ибо 7-zip показал тар, а винрар нет.

SAT31

В данном случае как я чуть выше сказал rar имитирует поведение команды tar -tf, а 7-Zip ведёт себя так, будто мы выполнили последовательность операций <декомпресс тарбалл> -> tar -t <тарбалл> и мы на промежуточном шаге видим результат первой операции. Но, оба варианта поведения равноценны т.к. результат будет один. Предпочтения при выборе того или иного варианта поведения целиком определяются автором разработки и каких либо формальных ограничений на эту тему не существует.

Пятая версия Винрара будет конкурировать с 7-zip по степени сжатия? Версии Винрара (что я пробовал) до 4.20 сжимают хуже.

Bulat_Ziganshin
Я добавил поддержку фрагментированного словаря при распаковке и выложил новую английскую сборку beta 3. Спасибо за совет

Использоваться под словарь могут до 32 блоков памяти. Оптимизацией скорости фрагментированного словаря я почти не занимался, так как ситуация нетипичная. Так что работает оно раза в два медленнее, чем нормальная распаковка.

Кстати, тестировал в реальных условиях я следующим образом. Запускал в XP WinRAR и нажимал в оболочке Enter на каком-нибудь .txt файле. WinRAR вызывал ShellExecuteEx, файл загружался в Notepad, а XP непонятно зачем подгружала wininet.dll. Эта .dll из одного сплошного блока на 1200 MB делала два на 750 и 450. После чего можно было приступать к распаковке архива с гигабайтовым словарем.

Victor_VG
Стесняюсь спросить, но может быть вы дадите автору заниматься программой, а не читать ваши бесконечные опусы? А для своих экспериментов и поклонников отдельную тему создадите? Где только вы, поклонники и опыты?

Цитата:

WinRAR вызывал ShellExecuteEx, файл загружался в Notepad, а XP непонятно зачем подгружала wininet.dll

могу предположить что ShellExecuteEx умеет открывать и URI, а для проверки "уж не URI ли это?" надо всенепременно вызвать wininet.dll. я не знал что ещё и с этой стороны засада


Цитата:

так как ситуация нетипичная

по моей статистике 14% пользователей сидят на 32-битной XP. другое дело что rar так быстро распаковывает, что и 2-кратное падение заметят только бенчеры

в общем, я рад что ты самый большой источник нареканий со стороны будущих пользователей ликвидировал. дальше уже по вкусу, хотя для 99.99% пользователей достаточно иметь "словарь до 128мб" вместо "или словарь ровно 128 мб или я отказываюсь работать". сложно представить рядового пользователя rar лезущим исправлять базовые адреса dll (хотя это очень просто, мы даже собирались автоматизировать вызовы editbin) ради увеличения размера словаря. а без этого отказ в архивации мало что даёт пользователю

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


Vitti
не пробовал, но могу предсказать что макс. сжатие rar будет в среднем процентов на 10 хуже чем в 7-zip

Bulat_Ziganshin

Цитата:

"словарь до 128мб" вместо "или словарь ровно 128 мб или я отказываюсь работать"

Это я тоже сделал. При упаковке или удалении из solid архива и нехватке памяти RAR выдает предупреждение и уменьшает размер словаря.

Цитата:

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

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

Что-то я тут нигде пока не видел инфы стоит ли вообще сжимать в рар5. Пока только недовольства, что он жмет хуже из-за убранных оптимизаций. Смысл в нем есть или нет - может кто-то сможет ответить, опираясь на тесты, а не на то, что бабки в падиках трут? P.S. Ссылки на тесты мне не нужны - мне нужны выводы по ним...

Xom9I4oK

Да, жмет лучше и быстрее чем rar4.
Народ тут находит специфические случаи, когда rar4 выигрывает.

Добавлено:
Benchmark

Цитата:

Но в 1985 году появилась утилита ARC, которая умела и "складывать" файлы в один, и сжимать их при этом. Так и появились на PC классические консольные архиваторы. Формат команд у них точно такой же, как у был у ARC почти 30 лет назад.

Ну еще был легендарный архиватор zoo, который пришел именно из Unix, работал под VAX еще.
Так идея складывать несколько файлов в один была реализована раньше ARC.
Кстати, tar + gzip сжимают лучше чем zip, ибо это то, что впоследствии стало называться solid архивы


Кстати, грусто что RAR не стал по настоящему межплатформенным архиватором, грусто, его так не хватает под Solaris...

Цитата:

Народ тут находит специфические случаи, когда rar4 выигрывает.

Скорее, оторванные от современных реалий. Ну не держит сегодня никто музыку в wav, а тексты в голом txt. Либо держит, но крайне редко.


Цитата:

Ну еще был легендарный архиватор zoo, который пришел именно из Unix, работал под VAX еще.

[more] Все с точностью до наоборот - он был разработан на PC и благодаря открытым исходникам портирован на многие платформы:


Цитата:

The zoo archiver was initially developed using Microsoft C
3.0 on a PC clone manufactured by Toshiba of Japan and
almost sold by Xerox. Availability of the following systems
was helpful in achieving portability: Paul Homchick's Compaq
running Microport System V/AT; The Eskimo BBS somewhere in
Oregon running Xenix/68000; Greg Laskin's system 'gryphon'
which is an Intel 310 running Xenix/286; Ball State
University's *T&T 3B2/300, **IX PC, and VAX-11/785 (4.3BSD)
systems. In addition J. Brian Waters provided feedback to
help me make the code compilable on his Amiga using
Manx/Aztec C. More recently, actual development, as opposed
to portability testing, has been done exclusively on my own
AT from PC's Limited running Microport System V/AT. The
executable version 2.0 for MS-DOS is currently compiled with
Borland's Turbo C 1.0.

Microsoft C 3.0 вышел в 85-м, Zoo появился годом позже. На PC именно ARC был первым [/more]


Цитата:

Кстати, грусто что RAR не стал по настоящему межплатформенным архиватором, грусто, его так не хватает под Solaris...

Ну вообще-то есть версии для Linux, FreeBSD, MacOS X. А раньше были еще для DOS, OS/2, BSD Unix, SCO, HP-UX, BeOS. Под Sparc, кстати, был. Пожалуй, не было версий только под "классический" Mac, Novell Netware и Itanium.

Так что вполне себе межплатформенный.

Цитата:

Народ тут находит специфические случаи, когда rar4 выигрывает.

Цитата:

Скорее, оторванные от современных реалий.

А ваши тесты, что «жать стало лучше, жать стало веселее» на чём основаны?
Ну так, справедливости ради.

тесты... а вот у меня такой случай был на winrar 4.20. имеем два компа. один...

второй

на win7 стоит winrar x64. им пакуем с максимальным сжатием и максимальным словарем в несколько потоков +3% на востановление раздачу bazar с рутрекера. ну например эту.
эту же раздачу пакуем на слабеньком компе простым winrar с опцией без сжатия словарь 4096 +3% на восстановление.
так вот. на слабеньком компе у меня архивчик размером меньше выходил. почему так - не знаю.

переводчику: косметический баг поправить бы

GoblinNN

Цитата:

так вот. на слабеньком компе у меня архивчик размером меньше выходил. почему так - не знаю

Очень хотелось бы при этом увидеть такой тест: раздача пакуется на каждом из компов - слабом и шустром. Затем распаковывается. Ну и для каждого компа стандартную таблицу следующего содержания:

1. оригинальный размер
2. размер после упаковки
3. время упаковки
4. время распаковки

Особенно интересуют п. 3 и 4

Женя,

1. В меню выбираем 'Settings'.
2. Вкладка 'Compression'.
3. Кнопка 'Create default...'.
4. Для 'Archive format' выбираем 'RAR' и 'Dictionary size', равный, например, '4096 KB'.
5. Жмём ОК.
6. Снова кнопка 'Create default...'.
7. Для 'Archive format' выбираем 'ZIP'.
8. Жмём ОК.
9. Опять кнопка 'Create default...'.
10. Повторно 'Archive format' меняем на 'RAR'.
11. Видим значение 'Dictionary size', равное '64 KB' (должно быть '4096 KB').

Уверен, ты меня понял.

Ikonnikoff
Понял Выложил исправленную английскую сборку beta 3.

Цитата:

Скорее, оторванные от современных реалий. Ну не держит сегодня никто музыку в wav, а тексты в голом txt. Либо держит, но крайне редко.

Таки да. Даже имея 500Гб винт уже не смотришь на эффективность: +/-20% по обьему для типичного пользователя - ничто. А вот скорость - все. Долгая упаковка/распаковка убивает, потому большие обьемы иногда жму в zip - просто потому что так быстрее.
Но rar5 да на многоядерной архитектуре да с 4-8 гигами памяти, да еще с настоящим RS - про zip никто и не вспомнит.
ЗЫ. Еще бы винда включила в состав проводника unrar.dll - было бы вообще здорово.
Кстати, это может оказаться еще одним путем распространения: распаковывать распаковывает, а при попытке модификации архива выдает сообщение "необходимо приобрести winrar". Хотя возможно некоторые покупают как раз для распаковки, тогда это может повредить. Это пусть маркетологи оценивают риски.
Для ассоциации с rar придется добавлять ключи в реестр, которые потом winrar при установке перепишет на себя, а при деинсталляции - обратно на unrar.dll

tomddf
Ну это просто смiщно.
Их (M$) антимонопольщики гнобят за браузер, а тут халявную рекламу рару будут делать.


Цитата:

Выложил исправленную английскую сборку beta 3.

А русская за 9 мая лежит. :(

Benchmark 15:37 14-05-2013
Цитата:

Очень хотелось бы при этом увидеть такой тест

сейчас никак. у меня остался только слабенький комп. тот что новее ушел сестре. но точно такое у меня было.
еще такой вариант помню. делаем архив на слабом компе с альбомом в mp3+jpg на скоростном сжатии+словарь 4096+3% на восстановление. отправляем по сетке архив на мощный комп.(ну думал мощный комп мощнее жмет) преобразовываем его с максимальным сжатием+словарь 4096+3% на восстановление. результат - архив получается больше на килобайты. мелочь вроде но всеравно. так что не известно где лучше жать и как.
а по скорости конечно на мощном шустрее все. но размер архива...

ALEX666999

Цитата:

А русская за 9 мая лежит.

ППР - распаковать текущую английскую сборку, взять оттуда (поимённо, пересобираются они):

Default.SFX - переименовать в DefaultEn.SFX
Rar.exe
RarExt.dll - может быть заблокирован по чтению, существующий сначала переименовать в каталоге куда установлен Rar в *.tmp, после перезапуска ОС его можно удалить
RarExt64.dll - может быть заблокирован по чтению, существующий сначала переименовать в каталоге куда установлен Rar в *.tmp, после перезапуска ОС его можно удалить
Uninstall.exe
UnRAR.exe
WinCon.SFX - переименовать в WinConEn.SFX
WinRAR.exe
Zip.SFX - переименовать в ZipEn.SFX

заменить текущие в каталоге Rar . Всё, дальше если надо ждать обновление перевода или самому его сделать. Сам именно так и делаю и у меня постоянно актуальная сборка с исправленными ошибками.

GoblinNN

Цитата:

косметический баг поправить бы

Спасибо, исправлено.

ALEX666999

Цитата:

А ваши тесты, что «жать стало лучше, жать стало веселее» на чём основаны?
Ну так, справедливости ради.

Писали вы не мне, но я отвечу
На работе СПС Гарант взял один файл упакованной самим гарантом базы данных data.str размером 2 гигабайта сжимал с опциями по дефолту + максимальное сжатие версия 4.20x64 сжимался 3m01s до 1,88 ГБ (2 021 245 526 байт), а версия 5b3x64 в формате rar5 тоже по дефлолту + максимальное сжатие 3m52s 1,86 ГБ (2 007 163 408 байт)

Analitik

Цитата:

2 гигабайта сжимал с опциями по дефолту + максимальное сжатие версия 4.20x64 сжимался 3m01s до 1,88 ГБ

Кстати, на таких еле-еле пакующихся данных в формате 5.0 на многоядерниках распаковка обычно заметно быстрее, чем для 4.x. Проще всего это увидеть, если сравнить время тестирования архива (распаковка в память). Только для повторяемости результатов надо тестировать уже лежащий в дисковом кэше архив.

А скорость упаковки в данном случае ниже из-за большего словаря, используемого по умолчанию - 32мб против 4. Если скорость важнее, можно и в 5.0 указать те же 4мб.