Comments 297
gzip не архиватор, а утилита для сжатия и распаковки, как и zstd. Архиватором в случае их использования обычно является tar.
7-zip же всё в одном, в этом от аналогичен arj, rar, ace и прочим утилитам, в основном популярным под Windows.
Как много дистрибутивов Linux вы знаете в составе которых нет tar?
Может быть потому, что tar создавали для записи данных на магнитную ленту, и его задача не архивировать, а обеспечивать непрерывный поток данных для записи, поэтому он и примитивен. Он не является архиватором, в привычном нам понимании, потому как ни чего не сжимает.
А вот gzip как раз сжатие выполняет, и поэтому часто работает вместе с tar.
Потокового функционала мне более чем достаточно, например я пользуюсь — распаковка архива одновременно со скачиванием его по ссылке, без сохранения промежуточного.
curl https://a.b/c.tar.xz | tar -xJкаждый инструмент нужно использовать там где он подходящий, если надо я и 7z использую, и образ диска с файловой системой, поддерживающей сжатие, и т.п.
curl https://a.b/c.tar.xz | tar -xJ
Эх, вспомнил как я, будучи совсем юным студиозусом, распаковывая огромный по тем временам архив через WinRar, как-то раз раз дико удивился двум вещам:
- А чего это все время вылазит ошибка распаковки? Архив то не битый точно
- И куда девается всё место на диске С? Вроде же на D распаковываю, я ж вам не ламер какой, честно — пречестно ))
Но, к слову, тогда быстро пришло некое осознание того, что «не все так просто в датском королевстве», я начал это дело копать, ну и в итоге это стало частью одного из кирпичиков знаний
Папку с файлами на вход отправить через шелл нельзя, поправьте, если не прав.
Это в каком смысле?
Если имеется ввиду графическая среда, то папка с файлами нормально перетаскивается в архив tar (со сжатием сверху или без) в Ark (в KDE).
Возможно, что в других графических средах (Gnome, Mate, Fly) оно тоже есть.
Если имеется ввиду какой-нибудь bash, то нормально принимает на вход папку и всю ее загоняет в архив.
В mc оно тоже неплохо добавляет папки в tar.
Если имеется ввиду конвейер, то какой архиватор может?
Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами. Настало уже время перейти на что-то более умное.
Оно, конечно, давно p7zip.
Но раз на два не приходится. tar и gzip в любом дистрибутиве линукса предустановлены (по крайней мере пока без него не видел), а другие архиваторы-разархиваторы (даже unzip) могут отсутствовать (встречал такие случаи, особенно на серверах). Это как zip во всех остальных случаях — средство гарантированного понимания.
В арче сейчас этот форк.
Поэтому способность tar получать данные на вход через pipe не имеет практической пользы при запаковке папки с файлами.
Ну очень даже имеет смысл, например в случае, когда вы хотите с удаленной системы в которой файловая система ридонли, взять какой-нибудь каталог и скачать его архивом. Берешь каталог, через find, пихаешь его в tar/gzip, кидаешь прямо в ssh а с той стороны прямо из ssh распаковываешь. И нигде не нужно создавать сам файл архива — ни там ни тут.
Вы конечно скажете про rsync/scp, но это уже каждый файл отдельно.
Для сжатия образа диска tar не нужен.
Так так и не сжимает, он «каталогизирует»
Папку с файлами на вход отправить через шелл нельзя, поправьте, если не прав.
Смотря что вы имеете ввиду. Список с файлами легко, через тот же find, но ведь папка — не является устройством и следовательно потоком.
Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами.
так таром и не сжимают, сжимают gzip, который с tar в хорошей синергии именно из-за умения работать с потоками.
А для просто сжатия — есть обычный zip/bzip/ну и наконец 7zip. Просто перейти на что-то более умное можно будет тогда, когда оно доступно в каждом дистрибутиве из-коробки. RAR в этом случае не подходит — платный (а зря), а 7zip бесплатный, и я новости радуюсь.
Тар-ом пользуются для архивации, потому что он как раз хорошо подходит для этой задачи, во всяком случае, не страдает таким идиотизмом (см ниже), как как при распаковке из рам-диска на рам-диск сохранять промежуточные файлы на системном жёстком. Да и производительность при поиске файла тоже неплохая, так как он перескакивает от заголовка к заголовка, считывая с диска минимум информации. А вот со сжимающими утилитами проблема есть. Здесь много чего следует усовершенствовать.
А что касается сжатия… следовало бы сравнивать с возможностями сжатия на уровне ФС. Это удобнее, так как не надо ничего запаковывать/распаковывать, это может быть быстрее за счёт использования инструментов уровня ядра, и это может дать большее сжатие за счёт большего числа файлов. Надо проводить эксперименты.
Например я не помню команду создания символических ссылок в windows. А в проекте — они используются. Просто делаю tar в linux, распаковываю его раром или семьзипом в виндовс — и имею каталог проекта с рабочими символинками, которые создали программы а не я. Если же копировать из линукса в винду средствами ФМ то не получается создать символинки, т.к. нужно обладать правами администратора. Может и можно как-то создать коннект между двумя операционками с админ-правами на винде, но мне проще вот через тар, чем что-то гуглить ради того что потребуется несколько раз в год :)
Например я использую tar для создания резервных копий дерева исходников. никакие гиты не заменят этот способ, т.к. гит удобен когда кладёшь в него что-то завершенное (фичу, фиксобаг, готовый таск). А на пути к этим этапам очень удобно сохранять рабочиепромежуточные версии (чтобы не убить, и не откатываться потом до последней рабочей версии из гита) — используя tar. Он внушат уверенность что после восстановления из tar — все меданные создания/изменения файлов будут оригинальными. Если же делать эти манипуляции через обычные средства (скопировать — вставить), то как минимум дата создания файла поплывёт. А эти данные между прочим помогают ориентироваться, не плохо помогают. И нет нужнды для таких операций, при дешевом дисковом пространстве — тратить вместо 20 секунд помещения в tar — например 80 на сжатие каким-то алгоритмом.
И даже если не брать профессиональную сферу, то именно в сохранении метаданных нахожу удобство tar, например резервное копирование семейных фотографий (где кроме jpg, еще и raw, не сжатое mov).
Никакие облака для этого не годятся, так же и тратить время и киловатчасы на сжатие терабайтных директорий — ну такое себе.
Просто подключаешь диск, и создаёшь архив tar на диск для резервных копий. И если основной диск умрет — потом можно восстановить и метаданные останутся как были, фотографии снятые в 2000х, так и будут иметь «время создания», «время изменения» — и вот это очень ценно. Когда прожил много лет, и накопил хороший личный-медиа-архив — вот эти вот «время создания 2002.12.31» — не менее ценно чем само содержимое фотографии.
И да, концептуально tar именно архиватор, и *.tar — это файлы архивов. К архивам в общем нет требования чтобы они были сжатыми. В тех же zip,rar можно паковать без сжатия. Более того в rar (единственном из всех) есть возможность создать архив с информацией для восстановления, при выключенном сжатии — архив получится больше чем размер оригинальных данных.
Очень полезная функция, например если потерялась одна/несколько из дискет — то при хорошем процентном (определяется в настройках) соотношении информации для восстановления — все данные восстановятся, как будто бы и не терялось ничего. В современном мире чуть менее но актуально, пример — умирающий носитель информации.
не нужно сгущать краски. связка tar+gzip давно не является стандартом, как вы давно уже не жмете в arj или zip. rpm или deb жмут в lzma, например, на сколько я знаю. другими дистрибутивами пользуюсь редко, поэтому ни чего не могу про их пакетные менеджеры сказать.
если под nix системами до сих пор этот тандем и используют для обмена файлами, то исключительно потому, что это работает на подавляющем большинстве систем, не зависимо от опций установки ОС. пока это работает, этим пользуются, особенно, когда требуется раздать файл +100500 тысяч человек. перестанет работать — перестанут пользоваться. ни кто не заставляет вас отказываться от 7-zip, если вы точно знаете, что ваш коллега/знакомый/друг точно сможет этот архив прочесть.
Функция сжатия в архиваторе опциональна, т.к. основная функция архиватора — собрать кучу файлов в один. tar и cpio это умеют и они оба считаются архиваторами.
Другие архиваторы (вроде 7-zip или старого доброго zip) пошли дальше и в них сжатие (и даже шифрование) является стандартной функцией.
Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами. Причём не монтировать его (это доступно только админу), а предоставлять доступ на уровне приложения, через библиотеку. Т.е. чтобы данные заливались на сервер и хранились там в компактном виде.
Разумеется, предполагается, что данные меняются крайне редко, а вот читаются довольно часто.
Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами.
Вы только сейчас проснулись? Webpack, initramfs, squash, cpio, iso-образов вам мало?
Причём не монтировать его (это доступно только админу)
С чего бы?
suid, polkitd, fuse. Куча вариантов.
Ну и в виде программного интерфейса это лет 20 уже существует
https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html
предоставлять доступ на уровне приложения, через библиотеку
physfs? В любом случае, все технологии, перечисленные в ответах к этому комментарию, существуют не один десяток лет.
Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами. Причём не монтировать его (это доступно только админу), а предоставлять доступ на уровне приложения, через библиотеку.
Ну это не совсем так. Программа ZipFolders делала это еще в начале 2000х
arj, ace
ha, да вы археолог!
Ну я ace довольно активно пользовался в своё время. До выхода какой-то из версии rar (2.90, кажется) он мне очень нравился.
arj тоже удалось застать.
Я бы к археологии скорее ain отнёс — не многие его застали, но жал он круче любого архиватора той эпохи, и был быстрым.
Нужно понимать, что 7zip стал стандартом дефакто для подавляющего большинства windows-пользователей, и он умеет не только в zip, но и в 7z, который на линуксе распаковать нечем.
И это очень хорошо, что теперь 7zip официально доступен на обеих платформах.
Вдобавок, научитесь не путать потоковое сжатие gzip и архиватор.
gzip — однопоточный и всегда будет проигрывать архиватору кторый умеет в многопоточность в разы.
вопрос к Tyooo: официальный 7-zip на линуксе в многопоточность умеет?
Ну и плюс pigz
1. Чтобы покромсать файл на блоки, его надо вычитать, а если это не файл, а лента или любое другое устройство последовательного чтения, то несколько потоков уже и не всегда выгодно.
2. Какие другие архиваторы с произвольным доступом? Почти все другие архиваторы, ради более быстрого сжатия, стараются анализировать блок побольше (а то и файл целиком), создать словарь, и только потом уже сжимать.
(Именно поэтому алгоритм, компрессии использующийся в gzip, быстро стал поддерживаться многими модемами, а потом и различными другими устройствами)
3. Уже несколько раз упомянули про pigz, если это необходимо, который многопоточный, при этом обратно совместим с gzip
А так поддержка ключей в 7-Zip для Linux есть:
-m{Parameters}: set compression Method
-mmt[N]: set number of CPU threads
-mx[N]: set compression level: -mx1 (fastest)… -mx9 (ultra)
Исходников Linux-версии тоже (пока?) нет. А автор по ссылке с официального сайта на вопрос о замене p7zip в будущем пишет, что не работает с Linux и ему будет сложно заниматься пакетированием всего этого добра.
Ещё, кажется, нет возможности добавления данных для восстановления архива.
По скорости и степени сжатия превосходил WinRAR, раньше по крайней мере.
Ну и бесплатность добавляет популярности.
Спасибо разработчику.
Не помню умолчания при установке, но можно зайти в tools->options и там поставить галочки на все типы файлов которые нужны.
А Shift-RClick — "открыть с помощью.." — "всегда открывать файлы такого типа" не катит?
А станете ли Вы устанавливать более одного архиватора? Понадобится ли условный WinRAR, если 7-Zip уже умеет распаковывать все необходимые форматы и наконец-то научится нормально интегрироваться?
У меня большинство архивов открывается Total Commander, 7-zip для редких случаев и shell menu как раз
Photoshop, скорее всего, прописался по кнопке "Изменить" в контекстном меню JPEG-файлов. Перезаписав Paint, который был там по умолчанию.
Редактор по умолчанию необязательно привязывать, обычно. Но tastes differ, как говорят англичане.
А станете ли Вы устанавливать более одного архиватора? Понадобится ли условный WinRAR, если 7-Zip уже умеет распаковывать все необходимые форматы и наконец-то научится нормально интегрироваться?Я стану. Потому что распаковывать-то RAR 7-Zip умеет, а вот упаковывать — увы.
у флешек такого вообще никогда не бываетТри раза «ха».
у винтов теоретически бывает, но настолько редко, что нет смысла заморачиватьсяUER у обычных HDD 1x10^-14, что, вообще говоря, не так уж мало.
По сути, самый удобный формат архивации вообще обычный zip, т.к. его поддерживает всё, что угодно, и вы будете уверены, что и вы, и ваш контрагент его всегда сможет открыть.Это называется не «самый удобный», а «самый универсальный».
Три раза «ха».
Даже если у вас это и произойдёт один раз на несколько тысяч операций, вам намного будет проще ещё раз свой файл туда записать, нежели каждый раз добавлять туда избыточную инфу для восстановления.
UER у обычных HDD 1x10^-14, что, вообще говоря, не так уж мало.
UER на HDD, это в общем случае не безвозвратная потеря данных, обычный винт задолго до возникновения невосстановимой ошибки выполнит релок проблемного сектора.
В общем, не надо лишней паранойи, а то так и до шапочки из фольги дойти можно. В конце-концов, копия бэкапа на другой накопитель решит 100% возможных проблем с накопителем, а не 0.1%, которые решает добавление избыточной информации.
Даже если у вас это и произойдёт один раз на несколько тысяч операций, вам намного будет проще ещё раз свой файл туда записатьЭто при условии, что у меня этот файл остался.
UER на HDD, это в общем случае не безвозвратная потеря данных, обычный винт задолго до возникновения невосстановимой ошибки выполнит релок проблемного сектора.Это не тот UER, что в SMART, это вполне конкретная характеристика. И да, мне будет не легче, если винт сделал reloc — информация-то потеряна.
Это не тот UER, что в SMART, это вполне конкретная характеристика.
Это тот самый UER. Но не суть важно. Как я выше дописал, если данные действительно важные, просто делайте две копии архива на разных накопителях. С накопителем может произойти всё, что угодно, и с вероятностью примерно 99.9% это будет отнюдь не то, от чего вам поможет примочка в виде добавления избыточности в архив.
где вы деньги на дополнительные накопители берёте?
Эм… а на календарь вы смотрели, когда я просил? 2021-й год, напомню. Четырехтерабайтный винт стоит $100. Потратьте как-нибудь то время, которые у вас уходит на возню с архивами/архиваторами, просто на приносящую деньги работу, и купите себе несколько таких. И я не ошибусь, если скажу, что четыре терабайта способны вместить весь контент, который вы там у себя можете нагенерировать, если это не куча видео и фото. Но видео и фото, к слову, это такие замечательные форматы, которые
а) не нуждаются в архивации
б) без особых проблем перенесут все те UER, если их не архивировать :)
Да, recovery record не панацея, и не замена бэкапа, но значительно лучше, чем ничего.
совершенно незначительно, если точнее. В том-то и дело.
Но вот два архиватора ставить уже не нужно, и в этом — плюс.
Если бы при установке архиватора было окно "Выбрать 7-zip стандартным приложением для архивов?" — вопросов бы не было совсем. Показывать каждый раз — это перебор, разумеется.
Мне кажется, гипотетической бабушке проще сделать клик с шифтом, чем искать в настройках нужную галочку: ассоциировать себя с 7z, со всеми архивами, выборочно с такими-то архивами… проще кликнуть)
Из любого правила, конечно, есть исключения, например «Бабуля КОБОЛ».
Если уж работа с файлами в Windows построена на их типах и привязанных к ним стандартных открывалках, почему бы просто не сделать как все, особенно учитывая отсутствие в системе мало-мальски достаточного собственного архиватора. Иногда складывается впечатление, что Microsoft состоит в негласном сговоре с разработчиками системного и прикладного ПО и именно по этой причине в системе за тридцать лет отсутствуют или находятся в зачаточном состоянии некоторые элементарно необходимые вещи.
Не все пользователи владеют контекстным меню.Если пользователь владеет установкой ПО, но не владеет контекстным меню, то он либо лютый консольщик, либо, простите, олух.
почему бы просто не сделать как всеКак все (в наши дни) — это весьма вероятно Electron-приложение, которое устанавливается в AppData, зачастую даже без возможности выбора.
в системе за тридцать лет отсутствуют или находятся в зачаточном состоянии некоторые элементарно необходимые вещи.Строго говоря, ОС должна уметь только загрузиться и дать возможность пользователю что-то запустить. ОС не обязана быть комбайном, который готов для любой вообразимой задачи, она должна быть достаточно компактной. В противном случае получим новый виток «Объёмных объектов» (3D — это же круто!), OneDrive, который нельзя удалить просто так (но ведь все пользователи хотят в облако фотографии котиков складывать!), возможность удалить «Калькулятор» (пф, у каждого смартфон в кармане, зачем им на компе считать?), но не «Карты» (а вдруг тот самый смартфон разрядится, а про сайты человек не в курсе) и так далее. Нет уж, давайте ОС будет давать в первую очередь возможности, а не решения.
Вроде как все околоайтишные люди знают, что если не уверен, есть ли у той стороны нужное ПО — отправляй в максимально распространённом/примитивном формате.
Потому что внучик продвинутыйесли он «продвинутый», то он либо заранее узнаёт про наличие 7zip, либо сразу использует ZIP для сжатия. Учитывая контекст, он отправил что-то вроде архива фотографий или песен (вряд ли бабушке понадобится что-то более сложное, в противном случае она тоже продвинутая и уже имеет у себя 7zip), и для этой цели простого ZIP-архива более чем достаточно. А откроется он средствами самой Windows.
Мы вроде бы обсуждали недостаточную (на мой взгляд) интегрированность 7-zip, а не гуглфото
Гуглофото тут приводится в контексте «ну и фиг с ней, с интеграцией, в 2021м-то году».
Опытный пользователь, если надо, быстро настроит. Неопытный, вроде упомянутой бабушки, никогда в жизни с тем 7-zip и не столкнётся.
И главное — если бы исходно программа привязалась с целевым файлам, удалённое управление не понадобилось бы.
Ещё полчасаВсего полчаса + пара минут, если вы установите бабушке 7zip через удалённое управление, а не «установи то, сё, пятое, десятое, потрать на это несколько часов, а я потом за 3 минуты всё настрою»
А вот прописывание дефолтных обработчиков на общепринятые форматы файлов меня вымораживает. Я как-то лет 5 назад из-за этого выпилил очень хорошую программу Audacious из репозитория сборки, которой пользуются каждый день очень много человек. Этот Audacious прописал себя открывать по дефолту на mime-тип
inode/directory. Ох сколько было мата… Так то, разработчики Audacious наверняка думали, что это удобно загружать в музыкальный плеер всю папку целиком и потом рекурсивно найти аудиофайлы всех форматов. Но они упустили момент, что папки бывают не только с музыкой, а еще и с документами и вообще со всякими файлами. И видя как открываться аудиоплеер, когда тыкаешь по папке — это как-то сбивает с толку.
в win95 как-то рановато, минимум в win2000, и то не факт
Там нет ничего из расширенной функциональности — разбиения на тома по размеру, управления степенью сжатия, сохранения/восстановления даты/времени, и много чего ещё.
Как и во многих других случаях, IMAPI например, складывается впечатление, что у МС есть отличные программисты, умеющие реализовать полноценно функциональность, доступную в сторонних продуктах, развивающихся на протяжении десятилетий, но при интеграции в ОС большая часть уже реализованной функциональности остаётся недоступной из-за криворукой реализации соответствующего GUI. При этом недостающая функциональность может быть вполне доступна из командной строки или хитровыделанного API, но это совершенно бесполезно для большинства пользователей.
нет возможности добавления данных для восстановления архива.
Вы про добавление CRC-суммы к каждому блоку данных, чтобы можно было идентифицировать испорченные блоки не теряя архив целиком? Так это, вроде как, в формате 7z встроено by-design.
В WinRAR есть возможность разбить архив на N частей, из которых любых M достаточно для распаковки (либо не разбивать архив, а просто добавить в файл избыточных блоков). 7-zip из коробки так не умеет, но можно создать файлы с информацией для восстановления с помощью MultiPAR.
Однажды, довольно давно, по моей вине очередной раз была задержана научная работа — сжал архиватором небольшую папку с исходниками проекта вместе с большим файлом экспериментальных данных с установки и впервые не протестировал архив — очень торопились. Как выяснилось позже, файл данных можно было легко получить снова, а исходники не распаковались из-за единственного сбойного сектора на hdd. Автор исходников стоически отнёсся с происшествию, сообщил, что работа уже сгорала в пожаре и однажды была украдена из лаборатории вместе с компьютером.
С тех пор предпочитаю добавлять информацию для восстановления в архив с важными данными. Потеря нескольких процентов объёма с лихвой компенсируется увеличением стойкости архива к повреждениям, превышающем обычную проверку CRC.
Потеря нескольких процентов объёма с лихвой компенсируется увеличением стойкости архива к повреждениям, превышающем обычную проверку CRC.Жёсткий диск очень любит сыпаться последовательными блоками, так что «нескольких процентов» мало, надо или приличные 15-20, или просто сделать копию на другой носитель.
Спасибо пользователям Windows за бета-тест ^^
Интересно зачем? Это как портированные фар когда есть мц
У mc внутри куча интеграций и кастомных настроек.
Кто привык — тот и будет юзать FAR. Лично мне он отвратителен.
Тут кто к чему привык). Кто-то пользуется и тем и тем, кто-то совсем другим.
Понимаете, продукты делают ± одно и то же. Но когда ты привык к логике действий и шоткатов mc и пробуете тот же фар, то начинается попаболь из-за того, всё делается по другому, другие шоткаты, другие плагины и интеграции. Ровно, как и наоборот.
ps. лол, мне за 5+ лет комментирования на ресурсе каждый раз минусят карму за комменты про FAR). Кто-то видимо очень ярый фанат.
Архиваторы сейчас как программы для записывания CD — в основном утратили свою основную функцию. Пользователи их используют, в основном, просто чтобы получить один файл, вместо рассыпухи и куда-то его переслать. Соответственно лучше тот, который быстрей, т.к. проще скачать в полтора-два раза больше, чем ждать пока оно распакуется.
Может вы имеете ввиду системное, сетевое применение? Я специально упомянул "пользователей". Действительно массивный контент (фото, видео) и так сжат по максимуму. А мелочь? Какая разницу сколько она там весит.
Это не их основная функция. Для шифрования всегда есть gpg, openssl и прочие утилиты.
И тот же tar, например, не умеет ничего шифровать сам.
если эта гипотетическая китаянка не умеет читать то какого простите ляда она сидит за компухтером?
а так файл зашифрованный тем же gpg по даблклику в винде предлагается рассшифроваться клеопатрой при наличии оной. удобство одинаковое.
здесь вы скажете что архиватор у неё в 99% случаев уже стоит а win gpg пакет нет… ну так это вопрос популярности а не удобства. и уж точно не имеет отношения к гипотетической китаянке
опять же вопрос насколько хорошо сжалось это одно и я с этим не спорю. удобство это другое
я про удобство
гуёвый ark создаёт из папки архив одним кликом. и юзверю знать не надо чем отличается .7z от .tgz (.tar.gz)
главное чтобы админ заморочился и поставил необходимый набор софта. за что кстати я в винде и любил 7-zip. он открывал любые архивы и не только архивы
Это как новый протокол QUIC (поверх которого работает новый HTTP3). Он совмещает в себе функции TCP, TLS, плюс мультиплексирование потоков в стиле HTTP2. И это даёт ему множество преимуществ по сравнению со старым решением, где надёжная доставка, шифрование и мультиплексирование делалось отдельными технологиями.
Визуально кажется что уровней столько же, но UDP там используется только для совместимости с существующими сетями, потому что только так сегодня можно добавить новый протокол транспортного уровня без замены всего железа по всему миру (что близко к невозможному). То есть его роль только в совместимости с существующими сетями. Сам по себе QUIC несёт себе функции TCP, UDP, TLS и мультиплексирования нескольких потоков через одно соединение (что ранее было частью HTTP/2), с кучей новых классных возможностей. То есть раньше часть задач транспортного уровня был вынужден брать на себя HTTP/2 (мультиплексирование нескольких потоков), что было не очень логично, и оно работало плохо из-за всей этой матрёшки (потеряли один пакет одного потока — застряли сразу все потоки), сейчас это ушло куда и положено, на новый транспортный протокол в лице QUIC (который ещё и заменяет TLS, так как только при такой интеграции можно избавиться от недостатков старой связки TCP+TLS+мультиплексор потоков).
Ну, теоретически можно было бы взять стек UDP/DTLS/SCTP/протокол приложения сверху.
DTLS шифрует пакеты SCTP, SCTP мультиплексирует потоки и обеспечивает надежную доставку (не страдая при этом проблемами TCP, когда один пропавший пакет тормозит всю очередь). Или не обеспечивает, если конкретно этому потоку такая доставка не нужна и он прекрасно живет с потерями. Или обеспечивает со стратегией "если за секунду пакет не ушел — выкидываем". Там много настроек.
Приложение работает уже поверх SCTP с абстракцией "много надежных зашифрованных потоков". Но у этого стека есть фатальный недостаток.
Синдром NIH — это когда какая-нибудь Apple делает свой изначально проприетарный ALAC, который совершенно непонятно зачем вообще создавался, потому что он буквально во всём хуже FLAC, который был создан раньше и был изначально свободным.
А если есть возможность предложить что-то лучшее, чем уже существует, то это уже не NIH, а развитие технологий. Если при этом компания кооперируется с другими заинтересованными сторонами для того, чтобы получить ещё более продуманный стандарт — это ещё лучше.
Тут больше претензия в том, что на выходе вместо модульных частей получается монолит, который хорош только в том, подо что его затачивали.
Да, разумеется, слоистое решение не идеал в плане эффективности. После DTLS можно не делать SCTP-хендшейк, например, а сразу инициализировать протокол каким-то состоянием. Насчет миграции, кстати, не согласен. DTLS в такое должен уметь, если правильно написать UDP-слой. Но это можно дорабатывать, сохраняя модульность. Заодно и реализации этих протоколов нормальные появятся, а не, упаси господи, usrsctp. Еще я с некоторым подозрением смотрю на попытку переизобрести TLS. Понятно, что там учтен опыт нахождения дырок в оном, но все же.
А пока, как я понял, на выходе получается вишмастер, который можно воткнуть, если приложению нужно мультипоточное надежное соединение. А если нужно чуть другое — уже нельзя.
Например, вам не нужно расшифровывать и разжимать весь поток данных, чтобы посмотреть какие файлы там хранятся.
Индекс-файл может создать и tar. Просто это указывается отдельным параметром.
И результат будет отдельным файлом, при этом решающим только задачу «получить список файлов в архиве без распаковки». Смещения начала файлов в нём не указаны, так что достать один файл он вам не поможет, даже если вы используете несжатый архив. Во всяком случае, именно так выглядит результат создания index‐файла с помощью --index-file.
Вообще некоторой доработкой формата можно было бы добиться нужного эффекта: просто научите tar дописывать этот index‐файл в конец архива (для совместимости: не в виде файла, а просто в виде некорректных данных после конца архива) и передавать xz параметр --block-list с такими значениями, чтобы один файл соответствовал одному блоку. Но это мало кому нужно, и вызывает необходимость что‐то делать с разными особыми случаями вроде «что делать, если файл обрезали после того, как tar передал --block-list но до того, как он начал запаковывать файл» (вопрос, в принципе, решаемый, если вы засунете xz внутрь tar или сделаете так, чтобы xz принимал на вход поток команд, а не просто поток данных).
Рулю службой поддержки пользователей и с лютой завистью смотрю на таких счастливых обитателей мира единорогов и радуг, как вы :) без обид, но 95% пользователей ПК независимо от национальности просто не поймут, что вы им предлагаете. А мне не нужно нести просвещение в массы, мне нужно убедиться, что проблема клиента решена наиболее простым и быстрым способом. Если бы я каждый раз заворачиваться в белый плащ и орал "ты дура тупая" на каждую китаянку — я бы давно свой выдающийся ум демонстрировал не коллегам, а другим нищим бездомным бомжам на привокзальной площади.
И, вроде, я не тупая китаянка, но в упор не понимаю, зачем бы мне устанавливать и использовать сразу несколько утилит, если от этого я не получу ровным счётом никакого удобства или выигрыша.
С учётом появившейся только в 20й версии поддержки Linux и отсутствием поддержки macOS не вижу ничего странного. В виндовых архиваторах такого почти нигде нет.
Под Linux и macOS есть p7zip. Это отдельная утилита, разработка которой приостановилась лет 5 назад (но в некоторых дистрибутивах уже перешли на его форк).
В остальном — да, всё так.
С другой стороны, а зачем в Linux нужен именно 7z? Есть же xz-utils, использующий те же алгоритмы сжатия (LZMA/LZMA2). В комбинации с tar он решает задачи сжатия и архивации данных.
2) Распакуйте 1 небольшой файл из 32 GB архива xz.
3) Сделайте инкрементальный архивы, дельта архивы, обновление содержимого архивов и т.п. под xz.
4) У вас Linux, но вам нужно передавать архивы и работать с ними под Windows.
6) Вы хотите гибко управлять компрессией.
7) Вам нужно user-friendly шифрование, чтобы самый тупой сотрудник потом можно это расшифровать под любой OS.
8) У вас Windows, но вам нужно получать архивы из Linux.
9) У ваших заказчиков Windows и вам нужен какой-то user-friendly архиватор для взаимодействия с ними.
10) Вы хотите удобно и кроссплатформенно работать с zip-архивами.
11) Вы хотите удобно распаковывать JAR, RAR, CAB и тому подобное.
12) Для вашего проекта нужна серьёзная работа с архивами из собственной программы.
7zip на голову лучше вообще всего и по всем параметрам. Единственный минус — отсутствие поддержки сохранения метаинформации POSIX.
Замените xz на pixz. Он индексирует tar при сжатии и сжимает блоками для быстрой частичной распаковки.
А 7zip не в своем формате сохраняет?
Из консольки можно посмотреть. Или поискать/написать плагин для mc/total commander. Благо для mc дальше баша лезть не придется.
Замечание было лишь по первому пункту. Если вам часто нужен листинг, то используйте форматы с индексом.
Если вы не сами архивы создаёте, а получаете извне, то у вас и выбора то нет. Что прислали с тем и работаем.
отсутствие поддержки сохранения метаинформации POSIX.
Там на самом деле достаточно было бы хранить только executable биты и все…
ну да, вы скажете давайте сделаем ещё копию архива и пусть оно будет децентрализовано
так и это плохо, ибо тогда архив нужно бить на части или если архив повреждён, то что же это тащить весь по новой или всё же дотащить битую часть?
и т.д. и т.п.
на календаре наминутачьку 2021 и этот ваш севензип не может ничего логически актуально действительно нужного
извините, но… нет
п.с.: да, я за рар и ничего более функционального пока не придумали
Соглашусь, что как опция такая функция не помешала бы. Но на мой взгляд свободность 7-zip перевешивает это преимущество RAR.
Проблемы с битыми архивами остались где-то в 90-х и нулевыхВаши бы слова да богу в уши.
Флэшки — крайне ненадёжный носитель.
Сеть — до сих пор порой есть вероятность скачать битый архив (а не у всех безлимитный гигабит, чтобы перекачивать, знаете ли).
Даже у HDD далеко не нулевая вероятность ошибки чтения/записи, а остаётся она на том же уровне, а объёмы-то растут.
7zip это сейчас единственный нормальный бесплатный опенсорс архиватор.
WINRAR всегда был неограниченно условно-бесплатным. Ну окошко, ну и что… Тем более, что лечится.
80% нужен удобный интерфейс и кроссплатформенность. Оставшимся — плюшки и свистелки. Сейчас эти два множества пересекаются только на 7zip.
WINRAR всегда был неограниченно условно-бесплатным.
В СНГ отношение к условно-бесплатному такое, что спасибо Рошалу он сделал для СНГ это бесплатным по умолчанию.
Но зарубежом к этому относятся серьезнее, особенно если не дома. И закупить winrar для компании в 10к сотрудников внезапно совсем недешево.
В СНГ отношение к условно-бесплатному такое, что спасибо Рошалу он сделал для СНГ это бесплатным по умолчанию
Не совсем так, в этом вина финансовой безграмотности разработчика. В нулевых Винрар (да и почти любое другое приложение) стоил 30 долларов и для людей было слишком дорого платить 20% зарплаты всего лишь за архиватор. До разработчиков только сейчас стало доходить, что лучше получить по доллару, но с каждого, чем поставить запредельный ценник, который оплатит доля процентов аудитории — игры в Стиме, приложения в Плэймаркете стоят от доллара, а Офис даёт плюшки в виде 6 ТБ и люди не столько покупают офис, сколько эти терабайты… Это как с налогами — ты увеличиваешь налоги, а поступления в бюджет внезапно уменьшаются… Если бы Винрар тогда стоил вменяемые 1...3 доллара, и был простой и удобный механизм оплаты без похода в банк, то даже школьники, наверное, честно покупали лицензию.
В СНГ отношение к условно-бесплатному такое
Вовсе не только в СНГ. Сколько встречал западных пользователей WinRAR — все использовали его так же бесплатно. У них покупка WinRAR даже своего рода «мем».
Про те 80% и не говорим
Символическая ссылка — это технически обычный файл, содержащий путь к тому файлу, на который он ссылается и имеющий атрибут, указывающий, что это символическая ссылка. Чтобы сохранять их вам нужно просто иметь возможность считывать и сохранять этот атрибут и читать содержимое файла‐ссылки вместо содержимого того файла, куда она указывает. Замечу, что вас при этом вообще никак не интересует, куда указывает символическая ссылка.
Сохранения информации вида «этот файл имеет тот же inode, что и файл X за пределами архива» (т.е. сохранения «жёстких ссылок») от архиватора не ожидают и, наоборот, все сильно расстроятся, если архиватор будет это делать (поскольку это либо уязвимость, либо бесполезная информация, либо повреждение распакованного файла). Сохранять информацию вида «это тот же файл, что и файл Y в архиве» можно, распаковывать потом с использованием жёстких ссылок — тоже, но обычно никто не заморачивается, поскольку жёсткие ссылки используются сильно реже.
Единственное: пока — с 7-Zip можно работать лишь в командной строке, графического интерфейса нет
В чем новость-то? Что в линухе появился архиватор 7z с CLI?
man 7za — никак?
Некоторым программам лучше не развиваться интенсивно, иначе они превращаются в годзил.
Единственной функции которой мне нехватает в 7z так это что-то наподобие виртуального диска(не знаю как точно назвать), чтобы можно было запускать например инсталляторы не распаковывая все.
1. github.com/billziss-gh/winfsp
2. github.com/dokan-dev/dokany
3. github.com/crossmeta/cxfuse
Сами Microsoft пилят ProjFS, но там свои особенности.
UPD: Я буду обновлять комментарии
Удалено. Надо обновлять комментарии прежде чем писать.
А зачем инсталляторы прятать в архив? Они сами по себе обычно пожаты.
Особенно забавляет когда архив с инсталлятором весит больше инсталлятора.
Поэтому tar умеет максимум executable бит сохранить, а не права.
tar умеет хранить права, uid, gid и даже acl.
Вдобавок все равно, если распаковывать под рутом, то можно потом chmod, а если под юзером, то как он в принципе имеет право создавать файлы, принадлежащие другому uid?
Бессмысленная вещь.
Вдобавок gnu tar этого не умеет, а выяснять на каком отдельно взятом дистрибутиве чего, tar нестандартный…
tar (проверял именно gnu) сохраняет не только uid/gid, но и строковые user/group, которые между системами уже весьма неплохо переносятся
Просто при запаковке можно указать ему строковые имя пользователя, группы, но он их переведет в UID/GID текущей системы и сохранит именно числовые значения.
Во-первых, зачем мне man, когда я тупо смотрю созданный tar-архив через hex-редактор и вижу, что там записаны пользователь и группа в виде строк? А когда я распаковываю tar на другой системе, они прекрасно мапятся на локальные uid/gid (которые иногда отличаются) — я это активно использую на практике, хотя в ман даже ни разу не заглядывал.
Во-вторых, ну а если вы хотите всё-таки ман — вот вам ман:
https://www.gnu.org/software/tar/manual/html_chapter/Formats.html#Attributes
When writing an archive, tar writes the user ID and user name separately. If it can’t find a user name (because the user ID is not in ‘/etc/passwd’), then it does not write one. When restoring, it tries to look the name (if one was written) up in ‘/etc/passwd’. If it fails, then it uses the user ID stored in the archive instead.
Во-первых, ну как бы да, а почему вы вообще ожидали, что tar каким-то волшебным образом обойдёт ядерные ограничения и сделает chown в обход штатных механизмов ограничения доступа?
Во-вторых, ну на самом деле если очень хочется, то можно — например, подключить какую-нибудь фейковую файловую систему (через FUSE например), которая не ограничивает chown, тогда tar успешно пропишет правильные uid/gid/user/group и без рута.
Это просто числа. Какому юзеру и группе они принадлежат на другой системе не имеет значения. Если у вас в системе nginx имеет uid 10, а в target системе 10 это cups, то распакованные файлы nginx будут принадлежать cups.
Или у вас вообще может не быть юзера с id 10.
В большинстве дистрибутивов (я не уверен, просто эмпирическое наблюдение) за такими известными юзерами зарезервированы одинаковые id.
tar + pixz
А теперь распакуйте 7zip архив без 7zip. Не понимаю проблемы.
7zip — первый же результат в поиске, к тому же он достаточно известный, чтоб свою страничку в Википедии иметь (тоже не самый надёжный источник, но от слабой паранойи от потенциально малварьно-рекламной ссылки в поиске поможет). И да, он уже собранный для Windows. Им просто удобнее воспользоваться.
Вы наверное веткой промахнулись и хотели мне ответить в другой. Потому что у автора комментария выше требование сохранять права, симлинки. Раз для бэкапов то еще и спец файлы пригодятся.
Причем тут простота, если он не решает поставленную задачу?
Тут задача стоит траншею выкопать, а вы предлагаете автомобиль вместо экскаватора, потому что автомобиль водить проще и найти легче.
Как вы себе представляете переносимость прав между Windows и Linux?
Подскажите удобный формат архивов для бекапов:
нужен индекс. tar.gz поэтому не подходит
неплохой уровень сжатия
метаинформация о файле (права), симлинки.
Юзеру нужны права. Он ищет альтернативу tar и gz. 7zip тут неприменим никаким образом.
Какой толк от такого бэкапа, если после его накатки система умрет?
А теперь распакуйте один файл из 10Г под виндовз из без pixz. Или просто просмотрите список файлов без pixz.Юзеру нужны права, а также поддержка Windows, хотя бы для распаковки. Он ищет альтернативу tar и gz. pixz тут неприменим никаким образом.
Какой толк от такого бекапа, если его даже накатить не выйдет?
pixz собирается на винде через msys2, достаточно стянуть PKGBUILD из арча и добавить префикс к пакетам. Просто никто собраный пакет не опубликовал в репозиторий msys.
Ну или WLS2 можно использовать.
Я уже потерял нить спора и куда-то не туда ушел.
Для обычного пользователя кроме 7zip ничего и не нужно. Для необычного пользователя выполнить make install не должно быть большой проблемой.
О нет! Всё это время я пользовался пиратским 7зипом! Что же теперь делать?
А с версией под mac что?
Я как-то попробовал разные архиваторы и вышло, что надо юзать gzip. Что упаковал 15 лет назад, и сейчас хорошо достается на любые линуксы. А опыт взаимоотношений показал, что "отдавай zip и там справятся". Всегда помни, что стой стороны "домохозяйка" будет распаковывать. Так что лишние 7% сжатия отступают перед 93% популярности.
Однако 7zip я всегда использовал для себя. В частности, то что занимало место, но придержать ещё надо, а 7zip жмёт хорошо и быстро.
Так что лишние 7% сжатия отступают перед 93% популярности.
С другой стороны, если человеку на том конце очень нужно, то он установит архиватор. Например, я в облаке держу и шарю файлы. Для меня критичнее всего — занимаемое место (облако не резиновое), а если качающий не хочет установить / обновить свой архиватор, то он волен поискать другой источник (учитывая редкость контента — искать он будет долго и не факт, что найдёт).
Если это соискатели на позиции разработчиков, то, очевидно, вам, как представителю работодателя.
С другой стороны, именно архивы 7z делаю достаточно редко, чаще я p7zip использую, чтобы создать самый обычный zip, который отправляю вантузятникам (потому что стандартный tar.gz не все могут открыть, был удивлен, впервые узнав об этом лет 15 назад!).
А вот когда я вижу архив в RAR, то однозначно понимаю, что сделал его вантузятник, выходец из бывшего СССР (потому что этой проприетарщиной больше никто и не пользуется).
Его можно назвать «швейцарским ножом» в мире архиваторов.Разве не Universal Extractor называют этим самым швейцарским ножом? Он конечно не умеет архивировать, но и 7-Zip всего в 4 умеет, а вот количество поддерживаемых форматов для разархивации у UniExtract какое-то просто запредельное, причём это не в стиле «9999 in 1», а всякие установщики, образы и даже видеоряды.
7-Zip — для наилучшего сжатия, UE — для чтения всего и вся.
Лишь бы ушлые товарищи не пытались им архивировать бэкапы архивов — баз и огромных данных.Иначе, даже сгоревший датацентр не поможет.
пока — с 7-Zip можно работать лишь в командной строке, графического интерфейса нет. Возможно, его выпустят еще через пару десятков лет, кто знает.
Но зачем юзерам Линукса ГУЙ? Это ж вроде фишка такая у них — «элитарность» с использованием «чёрного экрана консоли», в отличие от нас, мастдаеводов.
P.S: ох, чую подгорит и минусов соберу.
Версии 21.01 действительно нигде. Более того, несколько изменилось поведение автора с версии 19 — он полностью перестал выкладывать исходные тексты. Получается, что 7z 21.01 это вообще непонятно что за версия и кем выпущена!
Автора неоднократно просили показать исходники или показать репозиторий, но просто игнорирует такие вопросы.
Возможно, есть основания подозревать нехорошее.
Интересно. Я исходники качал с офиц. сайта 28.02.2019 на версию 19.00. Потом они исчезли, раз вы писали, что их нет? Кстати, контрольная сумма MD5 совпадает (это я так, на всякий случай сообщаю).
P.S. Написав "несколько изменилось поведение автора с версии 19" вы имели в виду после 19-й версии? Если да, то я вас не правильно понял.
Разработчик 7-Zip выпустил официальный билд для Linux спустя 22 года после выхода Windows-версии