Формат разный, дурашка
так зип должен меньше быть на выходе
бамп
бамп
Что за пиздеж? 10 ГИГАбайт в 6 МЕГАбайт?
В смысле 10 в 10
Каким образом сжимается в 1024 раза????????
Судя по разнице размеров в тысячу раз, у тебя этот архив пустой по сути, меньше бита информации на тысячу бит ёмкости. А это крайний случай, алгоритмы сжатия на это не настроены и никто не анализирует и не сравнивает их работу в таком режиме.
Сделай десять гигабайт нулей, и он у тебя успешно сожмётся до килобайта.
Ну, если там одни нули, то почему нет?
> Сделай десять гигабайт нулей, и он у тебя успешно сожмётся до килобайта.
как сделать? хочу удивлять учителя информатики
Может он текст сжимает, тогда это вполне реально. Текстуры модов татуировок для скайрима скачиваются в 40Мб, а при распаковке дают 5Гб, например.
Теоретически возможно, если, например, ОП-пиздабол сжимает 10 гигабайт текста "аааааааааааааааааааааааааааааааааааааааааааааааааааааааа..." ну ты понял. В искусственных условиях такое возможно. А так, я воспринимаю это как приглашение к холивару rar vs zip. Zip, конечно, лучше. В 2017 году только необучаемые дауны на винде пользуются winrar-ом, и обмениваются rar-архивами с таким же даунами.
А ваще, ОП, ты лет на 12-14 опоздал, тогда да, за zip пиздили ссаными тряпками, RAR юзали повсеместно, а прошаренные ставили 7z и терпели
А сейчас за что-то кроме зипа будут пиздить и желать подохнуть в муках
А сейчас за что-то кроме зипа будут пиздить и желать подохнуть в муках
Сделай например текстовый файл размером десять гигабайт с повторением одной буквы. Теоретически должно сработать.
Вот, не одному мне эта мысль в голову пришла.
так почему зип ужимает хуже, чем рар
под рукой нет кружки чая, поставь там пока и залей потом в архив, а?
ctrl+a,c,v,a,c,v
речь не о винраре, а о сжатии
Можно наговнокодить итерацией...
Открой блокнот, ткни по одной букве один раз и повторяй последовательность хоткеев из моего предыдущего поста. Охуеешь, отвечаю.
Сжимаю все файлы в хэш-сумму, зависимость есть, весит мало, подводных камней нет, советую.
Нахуя? Ручной тркд это шиттир, автоматизация наше всё.
Дебил.
Чому?
то есть ты хочешь сказать, если ужимать реальный файл такого размера, то на выходе зип будет меньше?
Гугли 42.zip и подобные zip-бомбы
Оче просто:
dd if=/dev/zero of=~/zeroes.txt count=20M
бамп
Zip-то же говно, просто rar еще и пропиетарное
>не сжимать в 2кXX в 7z
Не у всех есть bash, поэтому на питоне:
import os
file_handler = open("fucking_big_file.txt", "w")
while os.path.getsize("fucking_big_file.txt") < 10737418240:
file_handler.write("a" * 10000)
file_handler.close()
file_handler = open("fucking_big_file.txt")
file_handler.close()
print("ОП - хуй")
>2017
>пользоваться чем-то кроме lzma/lzma2
А разжимаешь как?
Это ты охуеешь, если попытаешь таким образом сделать 10 гб текста. Попробуй.
7z чтобы открыть один файл, распаковывает весь архив
Это и есть 7zip, алло!
это алгоритм, он есть не только в 7zip
Никак. Я же не свои файлы сжимаю.
Посоветуйте, чем лучше всего сжимать файлы, чтобы получить минимальный размер
А нахуя их разжимать когда у тебя есть хеш-сумма)) В виде хеш-суммы текст лаконичней выглядит прост.
xz
Зависит от настроек сжатия, и нахрена держать в архиве файлы, к которым нужен выборочный доступ?
бамп
Самый минимальный размер можно получить только универсальным архиватором rm (нулевой размер)
Зависит от того, какие файлы ты собираешься сжимать и как быстро тебе их нужно распаковать потом
время распоковки без разницы, главное ужать максимально
Ну представь себе - такие случаи не редкость, какой-нибудь архив внутренней переписки за 15 лет на пару гигов.
бамп
Да похер всем на разницу! 2017 год! Алло!
Сейчас важна универсальность.
так посоветуй чем ужать, чтобы на выходе получить минимальный размер
LHA
Как это??
Эх мне бы тёлку-шведку.
бамп
zip.exe самые пиздатые архивы
Скачиваешь zalupa_kentavra.zip.exe в 2 мегабайта, а при распаковке она занимает ~2 гига на жестком, 4 гигабайта оперативки и 99% процессорного времени. Делайте выводы.
Скачиваешь zalupa_kentavra.zip.exe в 2 мегабайта, а при распаковке она занимает ~2 гига на жестком, 4 гигабайта оперативки и 99% процессорного времени. Делайте выводы.
7zip сильнее на несколько процентов, чем WinRar, но сильно медленнее. По соотношению скорости к размеру WinRar оптимален. tar и прочее - полное говно. Ноунейм-алгоритмы могут сжимать сильно лучше или сильно хуже, в зависимости от конкретных данных, но все существенно медленнее WinRar.
ТЫ МНЕ СКАЖИ КАКОГО ХУЯ У МЕНЯ НА ВЫХОДЕ ВЕСИТ БОЛЬШЕ ЧЕМ СУКА НА ВХОДЕ
кому упало сжимать в 2к17? у вас компы разархивируют медленнее, чем можно скачать из тырнета
Tar как бы и не должен сжимать.
если ты про облако, то они по 10тб не выделяют
всмысле
ты заведующий гугл драйва?
Хуита. В цикле когда закрываешь и снова открываешь файл (нахуй кстати ты это делаешь) забыл аргумент "w" указать, не будет это говно работать как надо. Мудень блять.
я про бытовое использование, которое ненужно
Тащемта в питонах по дефолту там стоит "r" вроде как диванный, не помню.
Может он хотел чтобы пекарня ОПа ахуела от выгрузки в оперативу 10 гигов.
Это ты не шаришь.
бамп
бамп
>Тащемта в питонах по дефолту там стоит "r"
Вот именно. На втором шаге цикла трейсбек вылетит, и не будет никаких 10 гигов. Там же запись в файл производится, "w" нужно указывать обязательно.
Так. Падажжи. Кажется дошло. В файл ничего писаться не будет пока файл не "закроется". Все дерьмо будет висеть в оперативке, так чтоли? Блин, ну трейсбек же будет. Чет интересно стало попробовать.
Бля, как там этого школьника звали, который тоже десять гигов до десяти метров ужать пытался? Потом еще мем был про ебучего шакала.
Не сожмется. Ты долбоеб.
Блять у него цикл делает лишь первую строку. Тут нет табуляции.
>Вот именно. На втором шаге цикла трейсбек вылетит
Программист в треде. Пофиксил ошибку.
import os
file_handler = open("fucking_big_file.txt", "w")
while os.path.getsize("fucking_big_file.txt") < 10737418240:
try:
file_handler.write("a" * 10000)
file_handler.close()
file_handler = open("fucking_big_file.txt")
except:
continue
file_handler.close()
print("ОП - хуй")
>табуляции
Вы посмотрите на него, табуляции у него нету блять. Нормальные люди 4 пробела ставят.
А мне кажется, что в файл запишется сразу по вызову метода. Ну ты это, попробуй записать строку в файл, а после бесконечный цикл чего-нибудь и чекни, добавилось ли что-нибудь в текстовый документ.
Ты действительно хочешь начать это?
Проверял. В файл пишется только после закрытия файла. Похоже, поэтому говнокодер на каждом шаге цикла открывает и закрыавыт файл. Так то все правильно, кроме проебанного "w"
Не знаю. А ты?
Но ведь когда открываешь через "w", то у тебя удаляется вся предыдущая информация. Надо через "rw" открывать в таком случае.
Мне лень.
flush()? Не, не слышал.
Лол.
Ну вот смотри, у тебя есть текст из миллиона символов "а", файл .txt с этим текстом из миллиона букв "а", идущих подряд, весит, предположим, 8 гигабайт.
Рационально будет сжать это всё в одну буковку "а" и указать, что при распаковке нужно будет этот символ помножить на миллион раз. Получаем мизерный архив меньше килобайта, который при распаковке даёт 8 гигабайтный файл. Это, конечно же, все я утрирую, и делается немного сложнее, но суть та же. На основе этого делаются зип-бомбы, которые весят несколько килобайт, а при распаковке получаются сотни терабайт, из-за чего пека наглухо зависает.
Примитивная задача - всего навсего закатать говна на 10 гб в текстовый файл оказалась полной подводных камней. Проще 10 гб путем Ctrl+C Ctrl+V делать.
Да хуле сложного блять? 5 гигов оперативы я думаю у человека найдется. Просто пилишь 2 файла по 5 гигов и объединяешь их. хотя да, похоже я обосрался и даже тут будут подводные камни
в зип бомбе 4гб ужаты в архив, который в свою очередь ужат еще несколько раз
>Примитивная задача - всего навсего закатать говна на 10 гб в текстовый файл оказалась полной подводных камней.
Разработка ядра linux. Начало.
>Просто пилишь 2 файла по 5 гигов и объединяешь их.
Задача была только в том, чтобы просто запилить один файл на 10 гигов, а ты предлагаешь ее усложнить.
> 5 гигов оперативы я думаю у человека найдется
Думаешь у всех компьютеры чтобы в крузисы играть?
24 гига
Сервер?
Окей. Проблема записать разом 10 гигов в том, что не у всех есть 16 гигов оперативы.
А значит можно просто разом записать 5 гигов, скопировать файл и объединить их.
Эти бляцкие 5 гигов записываются методом того же говнокодера, только НЕ НУЖНО лишний раз открывать и закрывать файл. Мы все это делаем лишь раз.
Ну блять, знаешь, я не представляю как люди живут без 8 гигов. Это нахуй первое, на что стоит отложить деньги при сборке пеки.
>Проблема записать разом 10 гигов в том, что не у всех есть 16 гигов оперативы.
>А значит можно просто разом записать 5 гигов
>НЕ НУЖНО лишний раз открывать и закрывать файл.
>5 гигов. Зато НЕ НУЖНО лишний раз открывать и закрывать.
Вот так оптимизация. Ты из геймдева?
щас взял у зип бомбы конечный zip архив, весит 3,97 МБ
ужимаю тот же файл, на выходе 4,18 МБ
почему?
ужимаю тот же файл, на выходе 4,18 МБ
почему?
>Ну блять, знаешь, я не представляю как люди живут без 8 гигов
А я не представляю для чего может потребоваться 8 гигабайт одновременно (кроме ебанутых скриптов, конечно). Если я запущу сразу все говно которое когда либо использую около 4-х гигов займет, да и то меньше.
>почему?
Алгоритм тупанул над чем-то. Ты учитывай, что массово используемые алгоритмы сжатия заточены на универсальность. В каких то узких случаях они могут быть очень неэффективны.
> вся-суть-компрессии.жпг
Когда ты сжимаешь файл, то на выходе можешь получить архив с бОльшим размером, вот так поворот. А тут ты сжимаешь уже сжатое, т.е. получить бОльший размер значительно увеличивается. А вообще вроде как рар в раре не изменяет размера.
Да-да, это я.
Для игорей с комфортом. Для работы с адобами, буфером 4к изображений, И ЧТОБЫ ВАЛПЕПЕР ЭНЖИН РАБОТАЛ НА МАКСИМАЛКОХ.
Да вы все говноеды.
мимо .tar.gz
изменяет, только что проверил
Хммм. Ну ладно. Минус одно неверное знание в моей голове.
А ты думал, что если сжать архив на 3,97 мб то он будет 3,96 мб, потом 3,95 мб и так пока до 0, 00...0001 мб не дойдет и таким образом можно будет бесконечное количество террабайт уместить в микроскопические 0,00000...00001 мб, да?
Окей. Ну хотя бы 4 гига у вас найдется? Вот пилите 5 файлов по 2 гига и их клеете.
Вообщет тарболы вроде не для суперсжатия. Или я чет путаю?
Нахуя когда можн ПРОСТО небольшими порциями записывать, но часто, занимая 100-200 мб оперативы максимум. Откуда вы беретесь?
ты читать не умеешь
взял архив 3.97, разархивировал из него файл на 4 гб
его ужал и получил 4,18 МБ
вот и вопрос, почему не 3.97
И заебаться открывать миддиарды архиовов, да.
Хмм. Ну... хммм. Вот это хз.
Есть разные стандарты zip. Ты скачал в одном, заархивировал в другом.
потому что не сжимается твое говно.
попробуй полную банку с пивом сжать - хуй там.
а потом выпей содержимое и попробуй снова
это кстати странно, потому что если делать rar бомбу, то она будет весить куда меньше, чем зип бомба
Плюс возможно алгоритм сжатия делает какую-нибудь "случайную" выборку. Попробуй ещё раз то же самое сделать. Если получится один в один тот же объем - значит разные стандарты.
в rar добавили немало новых алгоритмов для специфических файлов, вот и всё. Но в общих случаях их сжатие будет одинаково.
по твоей логике ахуительной после каждой разархивации файла и последующий архивации архив будет весить больше, но это не так
брешь пустую банку. сгибаешь её. занимает меньше.
разгибаешь и выпрямляешь - занимает столько же...
ну эт босяцкий пример. или тебе с тех деталями нужно?
давай с деталями
Так зачем руками это делать? Написать скрипт для этого и все.
Простой вариант архиватора, есть 40 символов:
aaaaasssssdddddfffff
Сжимаем первый раз:
5a5s5d5f
сжатие 60%.
Сжимаем еще раз(опять спецсимвол, понятный нашему архиватору):
^4*5asdf
Сжатие 50%
Под впечатлением от истории анона выше про zip-бомбы я кинулся было писать скрипт который будет генерировать огромный файл с нулями. Но тут возникает такой вопрос. Перед тем как его заархивировать его нужно где-то хранить. Так что сделать терабайтный файл с нулями на своей пеке уже не получится. Следовательно, мне нужно вникать в структуру zip-архивов и пытаться сделать сразу небольшой архив, который, будучи скормленный архиватору будет разворачиваться в неебически большой файл. Второй вопрос - а что с того, собственно. Вот юзер начинает его распаковывать, ОС немного поглючит и выдаст ошибку о переполнении оперативки/места в логическом разделе. Нельзя же записать файл больше, чем выделено под раздел. Никаких фризов наглухо не будет. Или нет?
*20 символов
>Так что сделать терабайтный файл с нулями на своей пеке уже не получится.
Почему?
наебался блядь.
Простой вариант архиватора, есть 25 символов:
aaaaasssssdddddfffffggggg
Сжимаем первый раз:
5a5s5d5f5g
сжатие 40%.
Сжимаем еще раз(опять спецсимвол, понятный нашему архиватору):
^55asdfg
Сжатие 90%
*
лiл
Тарболлы вообще не для сжатия. gzip для сжатия
Смотря где он распаковывается, если это просто пека то космического эффекта не будет, а если это например роутер, который жрет обновление прошивки в формате зип, и ты ему подсовываешь зип бомбу, или андроид, которому ты опять же по ОТА притворяешься сервером обнов и пихаешь ему зип бомбу вместо прошивки, короче вариантов много.
Тарбол это и есть .tar.gz
>Почему?
Имелся в виду не конкретный объем файла, а очень большой объем файла. Так понятнее? У тебя может и есть винт на терабайт или больше.
А нахуя его делать очень большим?
import os
nb = 1
while True:
with open("fucking_big_file.txt", "w") as fp:
fp.write("a" * nb)
if os.path.getsize("fucking_big_file.txt") < 10737418240:
nb += 1
else:
break
Пофиксил вас обоих.
суть не в размере конечных файлов, а в том, что на оперативу будет нагрузка в несколько петабайт
у зип бомбы например конечные файлы суммарно весят всего 64 гб
> Перед тем как его заархивировать его нужно где-то хранить
Незачем где-то что-то хранить. Все архиваторы умеют в пайпы.
with open("fucking_big_file.txt", "w") as fp:
IndentationError: expected an indented block
сделай файл на 100 гигов, засунь один в зип, переименуй его, добавь в зип, повтори сколько надо
>суть не в размере конечных файлов, а в том, что на оперативу будет нагрузка в несколько петабайт
А почему она будет? Есть же своп и времнные файлы. Любой архиватор их использует. Не будет такой нагрузки на оперативу.
>на оперативу будет нагрузка в несколько петабайт
чего блядь
Индентация очевидна.
А вот это идея. Но мне кажется, возможно как-то сразу готовый zip сделать.
так есть уже зип бомба, чем тебя не устраивает?
f = open('fucking_big_file.txt', 'w')
f.write('a' * (10737418240 / 2))
print('Все соснули')
Как что-то может занимать в оперативе петабайт, если самой оперативы скажем 8 гб? Да, такой пнг при попытке его открыть завесит просмотрщик и забьет всю свободную оперативу, но и только.
процесс архивации суммарно столько будет занимать, причем тут твоя оператива
разархивации*
>https://xakep.ru/2015/09/03/png-bomb
С png интереснее. По идее, пикчи целиком в память выгружаются. Но все равно же, будет просто сообщение ОС о переполнении оперативки и фриз приложения, которое держит пикчу. Но за ссылку все равно спасибо.
Где он будет это занимать?
Ты ничего не понимаешь.
ты совсем тупой? как только память будет занята винда наебнется
Какая винда, 98? Может быть, а современные винды фризнут процесс и выдадут эррор, на этом все.
Зачем винде наебываться? У ядра для критичных вещей есть пулы (заранее выделенная память), поэтому ядру строго похуй. Наебнуться могут только кривые приложения, которые не обрабатывают ошибки аллокации памяти.
ну давай умник, попробуй разархивировать и посмотри что будет
долбаеб пытается спорить, при этом только сейчас узнал, как работает зип бомба
Бесконечный цикл, так как условие
if os.path.getsize("fucking_big_file.txt") < 10737418240
никогда не выполнится. В файл ничего не пишется во время отработки цикла.
Окей, анон, а теперь расскажи как кидать изображения с архивами в двощ и как изображение в 1 пиксель накрывает систему.
Нахуй иди, вот только что проверил, произошло именно так как я и сказал, фриз процесса, который я снял через таск менеджер, всё.
Свою хочу.
Архиватор не хранит ВСЕ данные в памяти при распаковке. Он хранит контекст, словарь, буфер, окно - называй как хочешь, зависит от алгоритма. А архиватор будет декодировать со словарем блок за блоком, декодированные блоки ему в хуй не вперлись, поэтому он будет писать их в целевой файл, вот и все. Количество занимаемой памяти при этом будет примерно одинаково на протяжении всего процесса.
хаха, а я только что твою маман опреходовал
пруфы давай
Выполнится. Открываем файл, пишем байтики, закрываем, проверяем размер. Если мало, пишем на один байтик больше, закрываем, проверяем размер, и т. д. Ну ты пони.
Хм, я думаю, что на это стоит смотреть как на возможность залить на двач картинку размером ~100 гб, чтобы петарды охуели, зайдя в тред, фризанув браузер и слив моментально весь лимит трафака.
А разве with сам открывает/закрывает файл каждый раз? Если файл не закрывать/не использовать метод который пишет в файл, то os.path.getsize() будет смотреть на пустой файл каждый раз, а все дерьмо будет копиться в оперативке/временных файлах питона. Или нет?
Да, with для того и сделали, чтобы файл был закрыт в любом случае автоматически при выходе из блока.
Хотел поумничать, а получилось как всегда :с
Буду знать теперь.
> трафака
трафика
фикс
> ограничения на 20 мб вложений
Хах, ну, пробуй.
Почему? Я ошибся в трех строках кода?
Так це ж на размер файла, а пнг-бомба весит нихуя. Вот только перед загрузкой пикча все равно открывается чтобы показать тебе превью, так что ты только себя этой бомбой бомбанешь.
Ты написал рабочую программу.
Ты тупой? Причем тут ограничение? Картинка может занимать меньше мегабайта. Раздувать ее будет отображающее ее приложение. Хотя, тогда получается это я тупой, так как только браузер фризанется, а слива трафика не будет.
Годный тред, кстати. Люблю тебя, ночной.
Как будто трудно запатчить скрипт загрузки.
Ну давай, расскажи, как бы ты патчил.
>Вот только перед загрузкой пикча все равно открывается чтобы показать тебе превью
Отключить картинки пред тем как загружать.
>только браузер фризанется
Так это ж заебись, хуяришь пнгбомбу в тред на нулевой и все, каждый кто заходит в бэ получает фриз браузера.
Кто запостит сами-знаете-какую пикчу в этот итт тред?
Господа, это технологический прорыв. У нас вновь появилось оружие, с тех пор как вайпалки стали бесполезными из-за капчи. И это оружие совершенно.
Макак не дебил, наверняка есть ограничение по ширине/высоте картинки.
Попытался, выдает "Ошибка постинга - файл слишком большой". Расходимся.
tar -cJf на тебя
Сколько пикча у тебя на харде занимает?
вот так
6 мегов. Похоже, у макаки действительно ограничение на размеры самой картинки.
Подтверждаю - есть. Из-за этого фоточки в 4к приходится ужимать.
Шаблонами разговариваешь.
Автоматизируют ПОВТОРЯЮЩИЕСЯ ПРОЦЕССЫ.
Доставьте вебмку про школьника который играет в майнкрафт и потом кричит "бляяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя", а потом его мамка орет "я тебе щас дам блять, блять".
>Перед тем как его заархивировать его нужно где-то хранить
Сохранил тебе в /dev/zero проверяй.
Опять сжимаешь, ебучий шакал.жпг
Как ты /dev/zero будешь архивировать, умник?
Окей. А если сделать изображение в 1 пискель, чтобы оно тоже роняло приложение, то ее залить удастся?
А такое изображение получится сделать? Тут как-бы суть в том, что именно охуенно большая пикча (много пикселей) сжата по стандартам png, а когда приложение пытается ее отрендерить оно фризится. 1 пиксель не имеет смысла. Или имеет?
cat /dev/zero | gzip -
Не так выразился. Не охуенно большая пикча сжата, а сразу делается такая пикча, которая при попытке рендеринга становится охуенно большой.
dd if /dev/zero | gzip > ti.hui
Не получится. Декодер посчитает, сколько ему нужно (ширина x высота x байтовнацвет) и не будет распаковывать из сжатого потока больше, чем необходимо.
Подарок треду
У /dev/zero нет конца. Этот архив никогда не доархивируется. Вариант анона выше с dd был лучше.
А это тут каким местом?
А у гзипа нет заголовка нормального. Достаточно будет нажать Ctrl+C.
Имелся ввиду пост совсем выше, где была проверка объема.
Ты не обманываешь? Порченый архив же получится.
А если формат без жёстких размеров, только построчно пиксели, при этом ещё и лзв зжатый. Есть такое?
Место на диске кончится и доархивируется.
> А если формат без жёстких размеров
Совсем поехавший? Как это по-твоему рисоваться должно, если декодер не знает хотя бы ширины?
И получится архив (а не файл) занимающий много места. Я другое заказывал.
А что если png со слоями? Дохуя слоев можно сделать?
У PNG нет слоев. Ненужные чанки, во-первых, наверняка режутся, а во-вторых, просто никем не декодируются.
Гугли теорию передачи информации, раздел про кодирование.
Опоздал немношк. Это к начулу треда.
Так, все. Загуглил. В png только один слой. Есть каналы всякие основанные на цвете и интерпретируемые приложениями, но это не то.
>? Порченый архив же получится.
Нет. Возьми и проверь
Символ перевода строки. В начале изысканий, в древние пионерские времена, такое могли придумать.
Альфа канал вроде есть. А многостраничные тифы принимаются?
по поводу?
Лол, я бы посмотрел на такое.
Так ты прикинь какой он будет когда разархивируется!
Блядь, ну ман дд сделай и посмотри какой командой размер ограничивается, че ты как блондинка.
Так ведь все знают, что хэши разжимают гуглом, торрентом и ныне почти умершими файлообменными сетями.
гугл драйвом?
Гугл-поиском, дебил.
саси
Так я и написал, что вариант анона выше с dd был лучше.
Очнись, ты серешь.
Торрент без DHT это и есть файлообменная сеть, но анально завязанная на трекер(ы) прописанные в файле.
Торрент с DHT это почти полный аналог какого-нибудь е-осла. Во многих клиентах даже есть поисковик, позволяющий искать файлы без участия трекеров или агрегаторов по нескольким трекерам.
блять, вы тут ебанутые? truncate -s100500G даст вам наполненный нулями файл размером 100500 гиг, занимающий на диске один сектор.
> Торрент с DHT это почти полный аналог какого-нибудь е-осла
Разговор был про хэши. В осле хэши идентифицируют файл, в торрентах - метаданные. Два разных торрента с одинаковыми файлами могут отличаться, потому что отличаются метаданные (банально порядок файлов).
бамп
Сколько раз не пытался ради эксперимента сжимать разные файлы разными методами 7-zip'ом, всегда хуета получалась, не больше 1 мегабайта сжималось в лучших случаях.
Но у всех есть питон.
Конечно. В системе среднего юзера может быть до нескольких десятков питонов.
print("kek")
Проверил.
Во-первых,
cat /dev/zero | gzip
не получится. Надо:
cat /dev/zero | gzip -ck > puk.zip
...
Ctrl+C
Во-вторых:
unzip puk.zip
Archive: puk.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of puk.zip or
puk.zip.zip, and cannot find puk.zip.ZIP, period.
Что я делаю не так?
> Что я делаю не так?
ZIP != gzip. Для декомпрессии есть gunzip, он же gzip -d.
>Что я делаю не так?
>gzip
>unzip
У тебя ошибка в коде
ГЕНЕТИЧЕСКОМ)))))))))))))))))))))
Питон есть на все основные платформы, в том числе и на винду. Его недолго скачать и установить. А вот утилиты GNU на винду не поставишь. Вернее, можно поставить какой-нибудь имитатор линукс, но это несколько сложнее чем скачать экзешник с инсталятором с python.org и нажимать "Ок", "Далее".
бамп
> А вот утилиты GNU на винду не поставишь.
Лож пиздежь. Есть MSYS, есть гораздо более охуенный MSYS2 с пакетным менеджером от арча. Прописываешь все это счастье в path, и у тебя винда с гнутыми командами. Можно даже баш юзать, если не смущает трансляция путей в single-root.
Любой 3.x качай.
Читать умеешь?
Читай:
Lates Python <номер версии> Release
Последний релиз Питон <номер версии>
Вот это и качай. Код выше для третьей версии.
Python 3.7.0a1 - 2017-09-19
Download Windows x86 web-based installer
Download Windows x86 executable installer
Download Windows x86 embeddable zip file
Download Windows x86-64 web-based installer
Download Windows x86-64 executable installer
Download Windows x86-64 embeddable zip file
Download Windows help file
Который?
Тест
Да понятное дело, что есть. Просто это сложнее, чем использовать универсальный язык сценариев, как раз для таких случаев.
Время 3 утра. я в щщи
Говори давай как команда распаковки целиком выглядит. У меня уже голова не работает совсем.
Если тебе похуй, то первый в списке. Если винда 64-битная, то любой из 64-битных инсталлеров. Очевидно же.
Опяттаки, могли быть форматы привязанные к разрешению конкретной машины с фиксированным разрешением - цга и пиздос, например. И вытекшие в мир пек.
cat /dev/zero | gzip - | gunzip -d > /dev/null
Схорони на случай зимних холодов.
в чем разница?
Сам пошел нахуй. В гуях распаковал))
Ну может и есть. Я, кстати, еще про RGB вспомнил и прочие SGI-шные форматы. В простейшем случае это файлы без заголовка, содержащие квадратные картинки с шириной, равной степени двойки. Какой именно степени - абсолютно похуй, зависит от размера данных. И даже сжатие RLE есть. Но макака такое, конечно же, не принимает.
"Во время распаковки файлов произошла ошибка"
Как я и говорил, битый архив.
Онлайновый инсталлятор, который скачает недостающее по ходу установки или офлайновый, который все нужное содержит в себе. Если ты не знаешь, зачем тебе это, то и разницы для тебя нет.
>gzip - | gunzip
>Во время распаковки файлов произошла ошибка
>Как я и говорил
Ты же тупой как хлебушек.
Даже если тебе не повезло, и ты прервал запись посреди блока, там все равно zlib-блоки - "битым" окажется только последний.
cat /dev/zero | gzip
Уже на этом моменте не получится. gzip нужно ключ -c указывать, чтобы он читал из пайпа, умник хуев.
> не принимает
Попробовал? мой герой
gzip -c нужно, чтобы он писал в stdout. А чтобы читал из пайпа, нужен дефис в качестве имени файла, и он там есть.
>Ты же тупой как хлебушек.
Может и так. Но в конечном итоге распаковывал я в гуях а не в терминале, в таком случае файловый менеджер сам вроде прочухивает, что там за архив и выбирает соответствующий архиватор. Или нет?
Хм. Жопой ман читал :с
Эм, добавлю, что речь шла не про команду с перетасовыванием из zero в null, а про уже готовый архив с некоторым количеством нулей из zero.
О чем этот тред?
>Блять, объясните, как такое может быть
сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб
сжимаю в rar, время 1 минута, на выходе 4 мб
Рошал пидор не оптимизировал zip-компрессор. Все силы ушли на rar. /thread
>сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб
>сжимаю в rar, время 1 минута, на выходе 4 мб
Ага, ага, а тред то о чём?
Потому что zip дописывает 6 мб кода вируса.
/thread
как оптимизировать
Написать свой упаковщик в zip на ассемблере, очевидно же.
не умею в ассемблер
Сочувствую.
Да как можно не уметь в ассемблер, там всего три команды!
бамп
>там всего три команды!
содомит
zip - один единственный алгоритм применяется ко всему
rar - применяет различные алгоритмы в зависимости от содержимого
Зип - это контейнер. Никто не запрещает использовать вместо Deflate какой-нибудь LZMA.
Какая-то там прогрессия.
pkzip
геометрическая.
Если ввести строку "a" * 100, копировать ее и вставить, копировать получившееся 200 "a" и так далее. И все равно охуеешь.
Для 10 гигов всего-то 33 шага.
> питон
Питух. Худший язык в мире. Сажи.
А какой лудший?
Двачую.
go-господин
Двачую
мимо программист на бейсике
Очевидный обжект паскаль.
Только что сделал с помощью копировать вставить файл нулей весом в 120 мб, закрыл-сохранил, открывал секунд 20, мне страшно продолжать.
Почему не хаксел?
notepad господин? Редактором пробовал открывать?
Которые сильно затянутся, так как охеревающий буфер начнет фризить текстовый редактор.
> редактором
edlin filename сойдет?
Нет идешки.
Да любой окромя блокнота.
MS Word
wordpad жрет 25% проца и пытается открыть 250 мб. Уже минуту жду.
>Почему не хаксел?
Я про такой задристанный язык даже не слышал. Поэтому. Еще хуже чем питон, наверное.
Бери edlin. Открывает мгновенно, базарю.
Саблайм попробуй. notepad++
Ща попробую вроде он был у меня.
Попробуй ex. Там такой хуйни не будет.
Че за хуйня, диспетчер задач показывает что нотпад жрет 2 гига оперативы, но файл всего 250 мб. Он показал нули но висит.
Он закрылся нахуй сам. лол
Помогайте блять, как увеличить размер файла не открывая его?
Это уже другой вопрос. 33 шага остаются. а как анон так высчитал кол-во шагов? Мимотупой
copy /b file.txt+file.txt result.txt
Это бейсик? (Как в винде язык шелла называется, это он?)
Куда вводить, у меня лапки.
>а как анон так высчитал кол-во шагов? Мимотупой
Один символ в юникоде занимает 2 байта. Берем условные 100 символов, умножаем на 2. Потом 200 символов умножаем на 2. Ну ты понел. И так пока не получим 2 (байта на символ) x 1024 (байтов в мегабайте) x 1024 (мегабайт в гигабайте) x 10.
Ну ты каждый раз удваиваешь количество символов. Т.е., на шаге 0 у тебя 1 символ, на шаге 1 у тебя 2 и т. д., на шаге n у тебя 2n символов. Для 10 гигов тебе соответственно нужно log2(1024×1024×1024×10) = log210737418240 = 33.321... (т.е., 33 шагов не хватит, будет 8 гигов, 34 будет много - в какую сторону округлять - дело твое).
Так нахуй, единственный кто смог открыть 250 мб это обычный нотпад. Щас попробую еще накопировать.
Старый дедовский способ увеличить размер файла не открывая его, все ученые в шоке! Достоточно просто...
ТЫ ПИДОР
Win+R, cmd, Enter, cd /d "путь к папке с файлом", Enter, потом уже copy.
Win+R -> cmd
кажется.
Заодно поясните почему ни один редактор останавливался на 25% использовании цп.
проиграл
Ебать я хуйню написал. Ну вы надеюсь поняли.
Нет.
Ни один редактор не стал использовать больше 25% проца. Даже нотпад который смог увеличить файл до 512 мб.
Хз. Может в ОС ограничение на процессорное время для этого приложения.
Падажи ебана, если написать cd то он откроет папку систем32. Что сделает d через пробел?
Вручную попробуй разрешить ему использовать больше ядер, или как-то повысить приоритет выполнения. (не знаю как это в винде делается, но скорее всего как-то в диспетчере задач)
В диспетчере на всех ядрах для редакторов стоят галочки.
При большом желании файлы можно читать и парсить параллельно, распределяя нагрузку на все твои 4 ядра, но так как это текстовые редакторы, никому в хуй не вперлось писать такой код. Тем более в нотепаде, который по сути своей оболочка вокруг системного поля ввода текста.
>Что сделает d через пробел?
Указывает, что ты переходишь на другой диск (логический раздел, если по-человечески), подразумевается, что путь нужно указывать абсолютный.
cd "папка" переходит в папку.
cd /d "папка" переходит в папку и меняет текущий диск на тот, где лежит папка.
Тогда мб в выделяемую память упирается, или в самом приложении ограничение на размер буфера.
Так, 4 гб почти готово, заставлю делать 8гб и пойду курить.
хуяк
Я в этом всем не шарю, но кто-то предложил сделать огромный пиксель. Возможно, в битмапе на этот один пиксель приходится 10гигов текста. но такое же невозможно, да?
тест
А ты его процессу приоритет ставил?
Почему от тебя байтами пахнет, ты нули сохранял?
Нет мам, ребята сохраняли, а я рядом стоял.
>сжимаю winrar-ом
>2k17
>Проприетарное платное говно с зондами
Ща допилю 12.5 гб и попробую заархивировать.
Чтобы оценить на сколько ужмется и меньше гигабайта было бы достаточно. Ты что хочешь-то?
Архиватором Бабушкина
Консервирует и хранит в погребе?
Переименуй в %дистр_чего_нибудь%.iso и выложи на торренты.
windows10_bez-zondow_aktivirovannaya_re-pack-by-VaSyAn_228.iso
game_of_thrones_season_10_leaked_footage.avi
У меня больше. Соси.
10BTC_access_key.txt
Да вы ебанутые.
.iso - охуенная штука в этом смысле. В .iso можно ссылаться из разных файлов на одни и те же сектора и делать исошки, которые хуй скопируешь, потому что все файлы на ней весят терабайт. И никакого сжатия при этом не нужно (но можно саму исошку упаковать в .zip для большего веселья).
Надеюсь, ты не думаешь, что я свои 400 гигов копипастом делал или даже записью нулей?
Сжал в рар до 6 мб. А я надеялся на 1 кб.
После архивации ноут минут 5 тормозил так как будто его выебали 12 гиговой елдой.
После архивации ноут минут 5 тормозил так как будто его выебали 12 гиговой елдой.
Мне все равно каким путем ты пришел к этом. Сам факт того, что у тебя хранится документ в 400 гигов вызывает недоверие к тебе, твоей личности, проводнику и твоему коту.
Может, мой тоже сожмешь?
Из интернета скачал?
Он это еще и на ноуте делал. Блять, со мной страшные люди на одной борде сидят.
Давай сожму, шли мне в личку.
Звучит эротично.
Посжимаем вечером друг другу архивы?
Пять минут.
Java.
Повторное сжатие дало 54кб для зипа и 10 кб для рара.
Короче, надо понять как устроены zip архивы. Можно же как-то вручную сделать. Щас буду гуглеть.
Заебешься deflate-поток собирать. Но так-то реально.
Бамп вишмастером https://files.catbox.moe/mfsdcn.zip
Блять. Я подумал можно сделать zip архив с файлом в котором символ повторяется N раз, открыть его хекс редактором, найти найти в нем N в двоичной системе исчисления и заменить его на 5 * 2^20. Не прокатило.
Внутри зипа во-первых размер файла в двух местах, во-вторых битовые (БИТОВЫЕ!) потоки, в которых и закодированы повторы. В Deflate LZ77 (т.е., вместо байтика пишется ссылка на предыдущий байтик в потоке и сколько он повторяется, но и сама ссылка, и счетчик повторов сверху еще хаффманом пожаты. В общем, это не хекс-редактором делается, и не в одном месте.
И вообще, все уже сделано до нас:
https://github.com/abdulfatir/ZipBomb
https://github.com/abdulfatir/ZipBomb
>abdulfatir
>ZipBomb
Проиграно
А что такого? Каждый Абдул должен хоть раз взорвать бомбу, пусть и архивную.
ОП - ебучий шакал!
А дальше что? Что дальше было? Ты еще раз сжимал? Каков предел, после которого размер архива не уменьшается? Распаковать пробовал, сколько времени заняло?
Дальше меньше, после 0 пойдет в плюс, так и делают накопители.
Дальше произошло то, чего не должно было произойти. Никому не пожелаю познать то, что познал я. Скажу только что тысячная архивация это точка невозврата.
может быть лучше в рар?
а смысл? чтобы какой-то долбаеб скачал и расстроился?
>а смысл? чтобы какой-то долбаеб скачал и расстроился?
Сейчас 99% контента всего по этому принципу делается и без раздутых текстовых файлов.
с какой целью
зачем спрашиваешь
затем, что ты написал об этом
Если так делают накопители, то как тогда появились первые накопители? Технологии пришельцев?
бамп
бамп
бамп
бамп
Вечером создай.
Нюфаг, это не из школьника пошло
Алексей бабушкин
бамп
бамп
Чтоб ты спросил.
сжимаю winrar-ом 10 гигов, в zip, время сжатия 6 мин, на выходе архив весит 10 мб
сжимаю в rar, время 1 минута, на выходе 4 мб