А может перейти на 7z вместо tar.xz?

Он не хранит владельца файлов, поэтому не применим для бекапов всей системы, но можешь им, например, содержимое некоторых каталогов хомяка сжимать

минус в том что в нём есть индекс ускоряющий работу, что не юниксвейно

Давно пора, да. Правда, кое-кому может стать «некомфортно»

То есть в тех случаях, где мне заведомо не нужны данные о пользователях (а у меня такого полно), можно использовать. Гут.

Стерплю.

Можно вообще использовать btrfs/zfs с включенным сжатием zstd и ничего в архивах не хранить больше, да и вместо бекапов снапшоты делать

Выше говорят, что он владельцев не сохраняет. Это минус. Но имеет индекс, это плюс.

Уважаемый, вы здесь с 2006 года, а несёте чушь.

Может он неправильно сохраняет права доступа или симлинки?

.gz, .bz2, .xz, .7z - это все алгоритмы сжатия контейнера, а точнее потока от tar.

А tar расшифровывается как tape archiver, разработанный ещё для записи данных на магнитные ленты.

Так вот именно tar хранит в себе все специфичные для linux права, симлинки, расширенные атрибуты, прочее.

И поток данных формируемый tar только сжимается целевым архиватором.

Вот если вы будете напрямую использовать 7z, без tar - тут могут быть нюансы.

Так что, учитесь, мой дорогой, учитесь, вы хоть и давно здесь, но учиться и думать никогда не поздно.

Вы, уважаемый, здесь с ещё более давних времён. Чем архиватор отличается от компрессора я знаю, поэтому избегаю неверного употребления этих слов. Вот я и думал, а есть ли смысл переходить с использования связки архиватора и компрессора на современный компрессор, который сам себе архиватор.

Лучше не вместо, а вместе

7z сам и есть контейнер

И чо? Который не умеет полностью всё то, что нужно для нормальной поддержки возможности файловых систем Linux.

Читаешь глазами или как-то по другому?

Вот я тоже так подумал, что он хочет tar.7z - тогда вообще без вопросов.

Это не отменяет тот факт, что он контейнер.

Давайте придумаем термин «архипрессор» и закончим на этом терминологические дебри.

Который не подходит для замены связки tar.xz, tar,gz, tar,bz2, о которой и указано в шапке темы.

И моё сообщение было именно о том, что в этой связки для сохранения posix атрибутов используется tar контейнер.

Хватит уже замазывать. Понятно, что ты не понял о чём я говорил и теперь пытаешься сказать умное.

rar тоже и контейнер и архиватор и zip просто. Ну используй просто их для backup`ов в Linux, где нужно сохранять права - вперёд.

Надо tar.zst (zstd), епта, он быстрее открывается, но уровень сжатия похуже (ненамного) чем у xz

Можешь перейти на .tar.7z — тут правда две команды понадобятся, так как 7zip в tar не интегрирован, но работать будет.

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

.tar.7z

Тогда проще будет оставить тот же xz, а то хрень какая-то получается.

zstandard есть, умеет в параллельность и разные степени сжатия

Чё только не придумают, лишь бы не пропатчить 7z на права и симлинки.

Самое главное преимущество для меня это возможность извлекать произвольный файл.

Мне всё равно, что кто-то не может понять элементарного и изложенного по пунктам.

Прочти ещё раз комментарий.

Там излагаются факты, каждый последующий подкрепляет предыдущий.

Так вот именно tar хранит в себе все специфичные для linux права, симлинки, расширенные атрибуты, прочее.

И вот после этого факта должно быть понятно, что я говорю в ключе, что просто 7z заменить связку tar.gz, tar.bz2, tar.xz не может.

Твои проблемы с пониманием изложения мысли с подкреплением фактами меня не волнуют.

Ты видимо каждое сообщение в разговоре с кем-либо рассматриваешь отдельно от нити разговора. Или общаешься очень короткими фразами и, видимо, с тобой так же нужно общаться.

Хотя думаю, что ты не сможешь понять комментария.

Да и ладно. Не моя проблема.

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

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

Будь хозяином себе, а не рабом своих слабостей.

C tar.{формат_сжатия} тоже так можно и в консоли и в графике.

Почитай man, если не умеешь.

Не, ты там себе противоречишь дальше. И некорректное по фактам заявление идёт первым.

Мне всё равно, что ты думаешь, не понимаешь - не моё дело.

Не можешь научиться признавать ошибку - не моё дело.

Можешь доказывать дальше, если некуда больше сил тратить.

Я выразил мысль в том сообщении, даже автор понял о чём она.

Может дорастёшь когда-нибудь.

Удачи.

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

Да, потому как если ты хочешь кому-то что-то объяснить и донести точку зрения нужны факты.

Я в своём сообщении их изложил поэтапно и в ответах тебе.

От тебя ни одного факта не было.

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

Первым же ответом тебе был факт. А у тебя просто оправдания почему тебе должны дать скидочку на твоё изначальное некорректное утверждение.

Ты умный? Твой 7z - контейнер и что? Он не подходит для полной замены связки tar.xz, т.к. не поддерживает posix атрибуты.

Я тебе ответил. Твой факт глуп и ты тоже.

Вообще, это уже какой-то троллинг твоей глупостью.

Прочти ещё раз заголовок темы, подумай что там написано. Хотя о чём я.

Rar, кстати, умеет сохранять метаданные POSIX. Это не отменяет его проприетарности, но справедливости для.

Сегодня этот факт глупый, завтра просто случайный набор букв можно на лоре будет постить - а чё, сами додумают если не дураки.

Спасибо, тут ошибся. Все атрибуты умеет сохранять, ACL тоже? Или только обычную для Unix / Linux схему прав?

Если не ответишь - погуглю.

Когда писал про rar тоже об этом подумал, т.к. это более старый формат. Но использовать его в linux системах для замены tar.{compressor} я бы не стал, его может не быть на целевой системе.

В любом случае спасибо.

Нет, там формат архитектурно недоработан.

Не говоря уже о том, что под названием tar скрывается не менее трех форматов, и у каждого свои нюансы. Но это ладно.

Нет, там формат архитектурно недоработан.

tar - tape archiver отсюда особенности.

Не говоря уже о том, что под названием tar скрывается не менее трех форматов, и у каждого свои нюансы. Но это ладно.

Про какие три формата ты говоришь?

tar - tape archiver отсюда особенности.

Это не особенности. Это недоработки. Когда тебе надо читать всю ленту, чтобы вытащить один файл в конце. Не думаю, что кто-то пользуется tar с лентами.

Что им мешало добавить оглавление в начале архива — вопрос риторический.

Про какие три формата ты говоришь?

The original tar format was introduced in Unix V7. Since then, there have been multiple competing formats attempting to standardize or extend the V7 format to overcome its limitations. The most common formats are the USTAR, PAX, and GNU formats, each with their own advantages and limitations.

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

Там не нужно всю читать. Формат ленты означает, что в начале где-то записана длина данных, а потом идУт данные, те ты читаешь n-байт, а потом делаешь fseek на это количество и так в цикле до самого конца, но плюсом является то, что ты можешь просто дописать данные в конце файла без его перезаписывания

переходи на squashfs.
полноценная поддержка всех файловых атрибутов и видов файлов *никс, «писался под *никс»
сжатие lzma xz. что сравнимо с 7z, жаль блоки сжатия небольшие, афигенно сильно сжать не получится.

7z не знает ничего и «вродеб знать не хочет» про юникс файлы.

как промежуточный вариант: rar. в 5 формате появилась поддержка пользователя, группы, прав доступа и еще чегото *никсового файлового. спец.файлов не завезли :(. зато есть и инедкс и солид-архивы и т.д.

использование tar для архивов, это конечно каменный топор. имхо конечно :)

Поддерживаю.

Итак, мы выяснили, что 7z нам не подходит в качестве архипрессора, потому что не сохраняет владельцев файлов.

А есть ли архипрессор, который и линуксовые атрибуты сохраняет, и позволяет файлы произвольно доставать из архипресса (хорошо бы ещё уметь подменять), и на венде нормально 7-zip’ом открывается? Желательно ещё чтобы формат был швабодный вдоль и поперёк, не как RAR.

к примеру мне нужно прочитать одну строчку в конфиге из 10гб бекапа системы позапрошломесячной давности.
для того чтобы получить хотя бы имя файла придется полностью перечитать весь tar, т.е. надо разжать 10гб к примеру тяжелого solid xz, а это жутко долго.
после получения имени файла, мне поднадобится прочесть этот файл. для этого надо либо где-то сохранить все расжатые десятки гигабайт (коэффициент для системы у меня был около 4 сколь помню, т.е. это 40 гб), либо заново их разжать, что опять долго…
ну ты понял :)

а со squashfs все происходит мгновенно. смонтировал на loopback и вот она вся система перед тобой - что хошь делай. хоть через mc побегай по ней и найди искомое, хоть файловые утилиты натравливай - все прозрано и быстро.

tar - tape archiver отсюда особенности.

Именно поэтому есть dar - disk archiver, который имеет свои особенности ;)

Чё только не придумают, лишь бы не пропатчить 7z на права и симлинки.

Меня так задолбало, что из-под двух разных виндов разные права - и каждый раз их надо настраивать, что завёл раздел для музыки в FAT32 - и он одинаково хорошо читается из-под любой винды, линукса, DOSа…

Это не особенности. Это недоработки.

В случае tar, допустим, но он не поддерживает сжатие.

Даже если там были бы заголовки без компрессора ты его всё равно использовать не будешь.

Формат заголовков должен выглядеть примерно так: файл такой-то смещение от начала такое-то.

Т.е. делаем вывод. Tar в начале должен просканировать всю сохраняемую структуру файлов с директориями, сформировать заголовок с тысячами файлов и указать для каждого вероятное смещение.

И ещё учесть, что если в процессе отправки потока данных на ленту вдруг появился или изменился файл всё это чтобы не сломалось.

Отсюда ещё один вывод: поток данных tar сжимается gzip, xz, bz2, следовательно реальный бинарные записанные данные будут сжаты компрессором и смещение указанное в таком заголовке всё равно не имеет смысла.

Ты не сможешь прочитать просто смещение.

Тут надо, чтобы gzip, xz, bz2 поддерживали возможность распаковки только нужного участка последовательности, что они сжали.

Во времена создания tar во всю шёл принцип kiss, следовательно tar решал задачу объединения множества файлов в один поток, перед каждым файлом добавляя информацию о его размере, имени, правах и прочих атрибутах и расположении в структуре, собственно это в имени и указывается.

Вот оно так и работает, зато надёжно.

The most common formats are the USTAR, PAX, and GNU formats, each with their own advantages and limitations.

Про pax, ustar слышал, видел новости, что к примеру в OpenBSD или FreeBSD хотят изменить формат на PAX или даже уже изменили и добавили ключ для включения старого формата.

Но более подробно не изучал.

Спасибо, есть что изучить.

Нет. Для получения списка файлов ты прочитаешь только имена файлов, а не весь архив (fseek, ага). А вот конкретный файл из архива, да, извлечет полностью. Но отдельный файл ты можешь сжать с помощью gzip, а потом через zgrep что-то искать, это конечно не по-настоящему построчно будет (что-то типа readUntil(«\n»)), он расжимает данные он блоками, а потом построчно в них ищет что-то

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

Поэтому тар пишет информацию о файле перед его записью.

Можно конечно формировать мета информацию и записывать в конец блока данных, но в этом случае нужно читать всю ленту.

Современные архиваторы 7zip, rar и прочие при формировании архива делают немного по другому.

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

Тело помещают во временный файл, а после окончания сжатия и формирования заголовка формируют результирующий файл с заголовком в начале.

В случае tar такой подход не применим.

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

ну это и так ясно без этого не вычислить размер данных

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

Сохранять промежуточное состояние на источнике нельзя.

Поэтому он сразу передаёт данные

header1:file1:header2:file2:header3:file3...

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

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

tar в связке с компрессором позволяет делать это на лету, без формирования сжатого архива целиком где-либо.

В этом его плюс, из которого проистекает другой недостаток.

Но аналогично этому можно, допустим по SSH лить сжатый архив на лету и распаковывать его на другом сервере, принимая поток по ssh, с другими форматами так не получится.