Ru-Board.club
← Вернуться в раздел «Программы»

» 7-Zip / 7z (часть 2)

Автор: WatsonRus
Дата сообщения: 26.03.2010 20:21
ALEX666999
05:33 26-03-2010
Цитата:
А как насчёт разницы в размерах сжатых файлов?

Не могу сказать, ибо 7-zip использую только для распаковки wim, nsis и прочих сторонних форматов.

Никогда даже в мыслях не было сохранять что-либо в 7z, пока не будет достигнут окончательный список поддерживаемых разновидностей алогоритма сжатия и пока не будут сделаны избыточные записи восстановления.
Автор: Victor_VG
Дата сообщения: 26.03.2010 21:41
WatsonRus

Кстати, ты не наблюдал в нём явление отказа обработки с сообщением о недостатке ОЗУ когда его по идее много? В принципе оно порождается его фрагментацией, и исчезает если использовать режим Large Memory Page с виртуальными страницами по 4 Гб. Но стабильность работы системы тогда вызывает у меня опасения. Проще оперативную память дефрагментировать заодно и выгрузив оттуда не используемые библиотеки и код.
Автор: WatsonRus
Дата сообщения: 26.03.2010 22:40
Victor_VG
21:41 26-03-2010
Цитата:
Кстати, ты не наблюдал в нём явление отказа обработки с сообщением о недостатке ОЗУ когда его по идее много?

У меня его по идее мало (256 RAM) , но такого не наблюдал. Но я 7-zip мало пользуюсь. И вообще стараюсь иметь с ним как можно меньше дела. Не люблю ресурсоемкие приложения, пожирающие ресурсы ради мизерного выигрыша в чем-либо (в данном случае в размере архива).
Автор: euheny
Дата сообщения: 27.03.2010 01:26
WatsonRus

Цитата:
И вообще стараюсь иметь с ним как можно меньше дела. Не люблю ресурсоемкие приложения, пожирающие ресурсы ради мизерного выигрыша в чем-либо (в данном случае в размере архива).

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

я вобще хотел бы отметить что 7зип - пример для подражания и МС со своей 7-кой очень далеко до такого качества
Автор: Ajaja
Дата сообщения: 27.03.2010 02:44
WatsonRus

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

Какие есть разновидности алгоритма LZMA? Если речи идет о LZMA2, то это новый алгоритм сжатия, а не разновидность LZMA. Точно так же нет никаких "разновидностей" у PPMd или bzip2.


Цитата:
и пока не будут сделаны избыточные записи восстановления

Для этого есть специализированные программы вроде par2, quickpar и т.п.
Автор: wolf0425
Дата сообщения: 27.03.2010 18:32

Цитата:
7зип - пример для подражания
ну-ну.
баг с обратокой списков файлов там как появился с рождения так годами переносится автором в очередную версию.
Хороший пример прикручивания сбокубантиков для улучшения степени сжатия на 0.1% за счет увеличения потребных ресурсов в 10 раз - это да...


Код: ps: пример списка:
h:\ver1\file.txt
h:\ver2\file.txt
Автор: WatsonRus
Дата сообщения: 27.03.2010 19:54
Ajaja
02:44 27-03-2010
Цитата:
Какие есть разновидности алгоритма

PPMd, LZMA, LZMA2, BZIP2 - это уже разновидности сжатия в архивном формате 7z. И я не уверен, что список закончен автором.

Цитата:
Для этого есть специализированные программы вроде par2, quickpar и т.п.

Почему-то в ACE, RAR, и даже древнем ARJ все это встроено... и многотомность нормальная имеется, а не ее жалкое подобие в виде разрезания готового архива на части и последующего склеивания при распаковке. Я это и Тоталом могу сделать.
Вообще 7-zip - убогий по удобству архиватор, все силы автора направлены на услиление сжатия. В юзабельности он никакой, и похоже таким и останется.

Если бы не возможность распаковки некоторых редких форматов, у меня 7-zip давно бы пошел в Корзину... молодой FreeArc и то юзабельнее при сравнимом качестве сжатия.

euheny
01:26 27-03-2010
Цитата:
у меня такое впечатление что речь не про 7зип, поскольку в моих глазах он всегда был чем-то противоположным

Тебе просто не видны все "прелести" работы с 7-zip на компе с небольшим размером RAM (256). А наращивать память ради архиватора я не собираюсь, для остального мне этого достаточно.

wolf0425
18:32 27-03-2010
Цитата:
Хороший пример прикручивания сбокубантиков для улучшения степени сжатия на 0.1% за счет увеличения потребных ресурсов в 10 раз

Вот это точное определение... Родовые черты - убогость в юзабилити, потребление ресурсов, но великолепное сжатие.
Автор: Ajaja
Дата сообщения: 27.03.2010 21:22
WatsonRus

Цитата:
Тебе просто не видны все "прелести" работы с 7-zip на компе с небольшим размером RAM (256). А наращивать память ради архиватора я не собираюсь, для остального мне этого достаточно.

7z - чуть ли не единственный архиватор, который предупреждает, сколько ему понадобится памяти для сжатия/разжатия. Если не гнаться за Ultra/Maximum compression level, то и проблем при запаковке не будет, и сожмет отлично. В любом случае, достоинство алгоритма LZMA не только в неплохой степени сжатия, но так же в том что для разжатия ему надо раз в 10 меньше памяти, чем понадобилось при запаковке. Так что, даже на слабом железе обычно нет проблем при распаковке файлов сжатых по-максимуму на мощных компах с гигами памяти.
Проблемы могут быть только с алгоритмом PPMd, тут память расходуется симметрично, сколько понадобилось при сжатии - столько надо будет при распаковке. В WinRAR при использовании алгоритма PPMd (сжатие текста, rar сам выбирает алгоритм автоматом) искусственно ограничили параметры алгоритма так, чтоб памяти использовалось не больше 128Mb. В 7z такого ограничения нет. Так что, если какой-то маньяк сжал большой файл в PPMd с использованием N гигов памяти и начал распространять этот файл в инете,то тут ему только доктор поможет. Защиты от "дурака" в 7z нет.
Автор: euheny
Дата сообщения: 28.03.2010 01:32
wolf0425

Цитата:
баг с обратокой списков файлов там как появился с рождения так годами переносится автором в очередную версию.

ну 7зип это не спец, а поп-прога, поэтому не удивительно - я не пользуюсь списками(как и подавляющее большинство)

WatsonRus

Цитата:
Тебе просто не видны все "прелести" работы с 7-zip на компе с небольшим размером RAM (256). А наращивать память ради архиватора я не собираюсь, для остального мне этого достаточно.

лично я не могу держать комп на котором не смогу хотябы как-то поиграть в самые современные игры
Автор: Spate
Дата сообщения: 28.03.2010 11:53
WatsonRus

Цитата:
У меня его по идее мало (256 RAM)

Ужас... у меня где-то валяется комп 10-летней давности, там и то памяти в два раза больше
Что это у тебя за комп такой? Может тебе хотя-бы ещё одну планку на 256 отправить ?
Автор: Ajaja
Дата сообщения: 28.03.2010 12:53
wolf0425

Цитата:
баг с обратокой списков файлов там как появился с рождения так годами переносится автором в очередную версию.
ps: пример списка:
h:\ver1\file.txt
h:\ver2\file.txt

Это не совсем баг, просто не понятно как архиватору в этом случае действовать (если пути абсолютные, а не относительные). Поэтому 7z в таких случаях запаковывает без сохранения путей. Winrar, например, обрубает букву диска, что может привести к глюку. Запакуйте rar-ом, например, этот список файлов:
D:\1\file.txt
E:\1\file.txt
и попробуйте после этого добраться до 2-ого файл стандартными методами.

Автор: WatsonRus
Дата сообщения: 28.03.2010 18:35
Ajaja
22:22 27-03-2010
Цитата:
Так что, если какой-то маньяк сжал большой файл в PPMd с использованием N гигов памяти и начал распространять этот файл в инете,то тут ему только доктор поможет.

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

Spate
12:53 28-03-2010
Цитата:
Что это у тебя за комп такой? Может тебе хотя-бы ещё одну планку на 256 отправить ?
.
А зачем? На мои нужды хватает всему, работает все шустро. "Тяжелых" приложений нет, ибо не нужны, в игры не играюсь, HD видео не смотрю. Компу семь лет, модернизировать уже бесполезно.
P-IV 2.0GGz, 256 RAM, видео (не встроенное) NVidia 64 Mb, XP SP3 чистая (не сборка).

Это только вам, геймерам, подавай супер-пупер современый комп.
Автор: Victor_VG
Дата сообщения: 29.03.2010 01:32
WatsonRus

Согласен. Такие чудеса попадаются, что и понять не могу откуда ноги у них растут.

Согласен с тобой и в этом. У меня так же машинка не новая: AMD AXP3000+ (Barton, FSB=400 MHz, Core=2100 MHz), сейчас плата A7V600 (VIA KT600), 1 Gb RAM, 4 HDD, nVIDIA GeForce 5600 (NV31), Audigy SE 5.1, IEEE1394, 2 DVD-RAM. Для работы пары компиляторов параллельно с СУБД хватает. А отдохнуть, так я могу и CD/DVD поглядеть, благо на полках их у меня стоит достаточно для этого. А вторая, под UNIX машинка с ещё более слабым процессором PIV 2,66 GHz, i915, 1 Gb RAM , 1 HDD 80 Gb, 1 NEC USB 2.0 карта, NVIDIA GeForce 8400 GT полуубитая - отдали ребята за ненужностью в офисе.
Автор: wolf0425
Дата сообщения: 30.03.2010 01:39
euheny
Цитата:
ну 7зип это не спец, а поп-прога, поэтому не удивительно - я не пользуюсь списками(как и подавляющее большинство)
7зип именно попсовый недоархиватор, ага.
подавляющему большинству пользователей 7зип совершенно до фонаря насколько хорошо он жмет - основным аргументом для выбора его, а не winrar - является фриварность 7z, а не лучшее на 0.1% сжатие.


Цитата:
лично я не могу держать комп на котором не смогу хотябы как-то поиграть в самые современные игры
лично я уверен что большинство компов покупается вовсе не для играния в игры. И что 80% покупаемых новых компьютеров - не годятся для 80% топовых игр, вышедших за полгода до этой покупки.


Цитата:
ps: пример списка:
h:\ver1\file.txt
h:\ver2\file.txt
Ajaja
Цитата:
Это не совсем баг, просто не понятно как архиватору в этом случае действовать (если пути абсолютные, а не относительные).
это именно баг, совсем баг, делающий бессмысленным 90% работы со списками. баг, жалобы на который автор игнорирует годами. А как действовать - как раз совершенно понятно: точно так же как действуют все прочие архиваторы, т.е. запаковывать ровно тот список, что указал пользователь, не пытаясь его глючно анализировать/оптимизировать для уменьшения размера архива на лишние 0.01%
И, кстати, проблем запаковать те же самые файлы не из пофайлового списка, а например из списка h:\ver1\*.txt h:\ver2\*.txt - у 7z нет, т.е. проблема именно во входном анализаторе списка, а не в невозможности правильно запаковать несколько файлов с одинаковыми именами и разными путями.

Цитата:
Поэтому 7z в таких случаях запаковывает без сохранения путей
не выдумывайте - именно как раз с сохранением путей и не пакует. архивы без сохранения путей нужны на порядок реже, чем с путями, особенно когда пакуют по спискам на 10000 файлов.


Цитата:
Запакуйте rar-ом, например, этот список файлов:
D:\1\file.txt
E:\1\file.txt
и попробуйте после этого добраться до 2-ого файл стандартными методами.
у меня стандартным средством частичной распаковки является FAR c плагином 7-Zip Alternative, так что добрался с первой попытки
в принципе нужный из двух можно и из комстроки распаковать - а вот с тремя наверно будут проблемы
Автор: euheny
Дата сообщения: 30.03.2010 02:02
wolf0425
наверное ты изначально пользовался раром
я тоже когда-то пользовался раром и, если честно то я раньше пользовался списками в 7зип, но всегда находил решения
нужно быть немного гибким

Цитата:
лично я уверен что большинство компов покупается вовсе не для играния в игры.

говорится так, но подразумеваются как раз игры - мы же люди
Автор: wolf0425
Дата сообщения: 30.03.2010 02:30

Цитата:
наверное ты изначально пользовался раром
когда я пользовался изначально - рара ещё в проекте не было.
lha и arj были - и рар от них всё полезное и унаследовал, и своего добавил нехило. 7z тоже пытался отнаследовать от рара - но делал это крайне халявно и давно съехал с оптимизации удобства использования на оптимизацию плотности упаковки. Которая мне нахрен не сдалась - 1% разницы в размере архива не решает совершенно ничего, особенно если за него ещё и временем/памятью доплачивать приходится.


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

В реале список на 4-5к файлов генерится внешней программой, и таких пар в нем - десятки. ВСЕ прочие архиваторы - не имеют никаких претензий к многократному повторению имени (с разными путями) в одном файл-списке, только 7z такой особенный.
Перевести вариант генерации списка на чисто внутренний генератор, из h:\file.txt с подкаталогами - не вариант из-за того, что 1. придется прописывать непомерное количество исключений для гарантированного непопадания лишних файлов в архив (уж больно примитивен язык масок 7z) 2. даже без исключений - полный список за запаковку генерится встроенной генерилкой 7z на порядок дольше, чем внешней программой. 3. предыдущие два пункта недостатком 7z не являются - они у всех архиваторов тормозные. Но остальные то архиваторы нормально поддерживают уже готовые списки.


Цитата:
говорится так, но подразумеваются как раз игры - мы же люди
угу, и те кто платят за компы - тоже люди, считают что деньги считать умеют.
Автор: Victor_VG
Дата сообщения: 30.03.2010 09:03
wolf0425

Вспомни что например у того же bzip2 своих проблем не мало - например он иной раз повреждает бинарники, особенно если они не находятся в во вложенном каталоге-контейнере предварительно сжатом tar. Сам десятки раз этот глюк встречал. Причём у него есть особенность - он портит только PE файлы, а ELF не трогает. Но, тот же 7zip пакует и те и те не повреждая. Лишнее доказательство того, что для каждой задачи с её вводными нужен собственный инструмент. А общие рассуждения на тему "Если бы у рыбы были вши.." давай оставим школярам - им информатику преподавали, Микрософт готова их посадить бесплатно а свою иглу Win7, а нам-то с тобой это не надо - у нас есть наработанный годами опыт, и зачем нам спорить с людьми которые абсолютно убеждены в том, что то, чему их научили - истина в последней инстанции. Всё одно упрямцев не переубедить, пока они сами на своём опыте не придут к тем же результатам. Да и то, коли им лень-матушка не помешает.
Автор: Ajaja
Дата сообщения: 30.03.2010 18:35
wolf0425

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

Не знаю, проблем при запаковке списка файлов с относительными путями у меня никогда не было:
file.txt
ver1\file.txt
ver2\file.txt
Пакуются без проблем.


Цитата:
т.е. запаковывать ровно тот список, что указал пользователь, не пытаясь его глючно анализировать/оптимизировать для уменьшения размера архива на лишние 0.01%

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



Цитата:
И, кстати, проблем запаковать те же самые файлы не из пофайлового списка, а например из списка h:\ver1\*.txt h:\ver2\*.txt - у 7z нет, т.е. проблема именно во входном анализаторе списка, а не в невозможности правильно запаковать несколько файлов с одинаковыми именами и разными путями.

Это в какой версии 7-zip-а??? Никогда с таким не сталкивался. И сейчас последняя версия v9.12 не хочет такой список архивировать с сохранением путей.


Автор: euheny
Дата сообщения: 31.03.2010 02:22
Victor_VG

Цитата:
у того же bzip2 своих проблем не мало - например он иной раз повреждает бинарники

был у меня случай, когда рар восстановил неправильно файл
crc32 совпадал, однако exe-шник был испорчен
насколько помню в файле было две одинаковые пары байт, так вот рар их перепутал
Автор: Victor_VG
Дата сообщения: 31.03.2010 07:59
euheny

Это уже хэш-коллизия алгоритма. Случай к сожалению не редкий при применении простых алгоритмов типа CRC-15/16/32 или MD2/MD4/MD5. Для SHA-1 он так же вероятен, и хотя его вероятность на сегодня оценивается намного ниже, но она существует и конечна. По современным оценкам в алгоритмах серии SHA-2 возможность возникновения хэш-коллизии предотвращена, по крайней мере на сегодня достоверной информации об обнаружении предпосылок их возникновения или сообщений об ошибках данной серии алгоритмов у меня нет.
Автор: Bulat_Ziganshin
Дата сообщения: 31.03.2010 08:11

Цитата:
По современным оценкам в алгоритмах серии SHA-2 возможность возникновения хэш-коллизии предотвращена

круто! наконец-то найден споосб сжать любой файл в 20 байт LOL
Автор: Ajaja
Дата сообщения: 31.03.2010 11:10
euheny

Цитата:
был у меня случай, когда рар восстановил неправильно файл
crc32 совпадал, однако exe-шник был испорчен
насколько помню в файле было две одинаковые пары байт, так вот рар их перепутал

Наткнутся на коллизию CRC32 достаточно просто, там всего 32-битный хэш. Вероятность встретить повторяющийся хэш больше 1/2 уже на количестве блоков ~80000. Другими словами, если у вас на компе 80000 разных файлов, то вероятность того, что среди них найдутся 2 файла с одинаковым CRC32 больше 50%.
Я, честно говоря, удивлен, что rar использует его для реализации recovery-алгоритма. Для этих целей он однозначно не приспособлен. В том же древнем PAR2 давно MD5.

Victor_VG

Цитата:
Это уже хэш-коллизия алгоритма. Случай к сожалению не редкий при применении простых алгоритмов типа CRC-15/16/32 или MD2/MD4/MD5. Для SHA-1 он так же вероятен, и хотя его вероятность на сегодня оценивается намного ниже, но она существует и конечна.

Вероятность случайно встретить коллизию 128-битных MDx хэшей практически нулевая, про 160-битный SHA1 я вообще молчу. Другое дело, что для MDx существуют специальные алгоритмы (атаки) позволяющие достаточно быстро найти коллизию (подобрать два куска данных с одинаковым хэшем). Но это проблема криптографии. Для проверки целостности архивов и реализации recovery-алгоритмов предпочтительней использовать как-раз MD5, а не SHA1/2 т.к. он намного быстрей.

Автор: Victor_VG
Дата сообщения: 31.03.2010 12:56
Ajaja

Не столь уж и нулевая вероятность хэш-коллизии для MD5 - до 2,7*10-5 - это очень много.
Автор: cuneiform
Дата сообщения: 31.03.2010 15:38
Подскажите плиз чота у меня перестал он прально архивить: пришлось снова зарарить дистрибутив 375 мегов на 328 мегов. А 7-zip дает 337 мегов, начинает зипить при 101% .Может я размер блока непрально выставляю (по размеру ФАЙЛА) ? Ну в каком случае может он 101% показывать при сжатии?! zip при сжатии тока 88% показывает, а не 101%. В чем тут дело?

Автор: egor23
Дата сообщения: 31.03.2010 16:07
cuneiform
LZMA - особенность LZMA, при упаковке несжимаемых данных
LZMA2 - Вам в помощь
Автор: cuneiform
Дата сообщения: 31.03.2010 16:30
THX за инфу. LZMA2 в 7-zip пока не попал? А в каком / каких испоьзуется уже или рекомендуется? - Тогда выгоднее такие файлы просто зиповать?
Автор: egor23
Дата сообщения: 31.03.2010 16:51
cuneiform

Цитата:
А в каком / каких испоьзуется уже

как обычно используйте последнюю beta-версию
на данный момент 9.12beta

Добавлено:
или, если используете LZMA? добавляйте такие несжимаемые файлы в архив после с - Без сжатия
Автор: cuneiform
Дата сообщения: 31.03.2010 17:18
Тогда последний кажется вопрос: а LZMA2 - это только многопоточность (скорость), которую надо вручную выставлять (1 поток или 2) в проге?
Автор: Ajaja
Дата сообщения: 31.03.2010 18:05
Victor_VG

Цитата:
Не столь уж и нулевая вероятность хэш-коллизии для MD5 - до 2,7*10-5 - это очень много.

Вероятность случайного(подчеркиваю) возникновения коллизии зависит от объема данных. Если я правильно подсчитал, то вероятность возникновения коллизии порядка 1e-5 для идеального 128-битного хэша может появится только при подсчете порядка 1e17 таких случайных хэшей, а вероятность возникновения >0.5 при количестве выборок уже порядка 1e19. MD5, конечно, не идеален, но вряд ли для него эти цифры будут сильно отличаться.


Автор: euheny
Дата сообщения: 01.04.2010 00:37
cuneiform

Цитата:
Тогда последний кажется вопрос: а LZMA2 - это только многопоточность (скорость), которую надо вручную выставлять (1 поток или 2) в проге?

больше потоков - больше скорость
и вот не ручного варианта для гуи видимо нет

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135

Предыдущая тема: RDM+, TSMobiles и VNC+


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.