Чем вы архивируете файлы?

ошибаешься.

find ... | xargs tar -cf - | gzip
#сработает так, как ты хочешь

$ (tar cf - 'New_Impedance test.xls' ; tar cf - VPN-1_VPN_Interoperability.pdf) > test1.tar

$ ls -lrth New_Impedance\ test.xls VPN-1_VPN_Interoperability.pdf test1.tar
   214K Jan 16  2013 VPN-1_VPN_Interoperability.pdf
   376K May  5  2013 New_Impedance test.xls
   600K Feb 18 14:53 test1.tar

$ tar tf test1.tar 
New_Impedance test.xls

cpio стар и больше не распространён

А как же initramfs?

А по теме, для названных задач - tar с(z/j)f .

gzip

Типичный бсд-ун.

tar.xz
7z

tar, zip

пока что проблем не было

и не будет скорее всего, если у тебя 4+Гб

ошибаешься.

(tar cf - 'New_Impedance test.xls' ; tar cf - VPN-1_VPN_Interoperability.pdf) > test1.tar

tar tf test1.tar New_Impedance test.xls

а ты что хотел-то?

Откуда я знаю, чего ТЫ хочешь? Доказать, что я не угадал твои извращённые хотелки? Ты победил.

cpio стар и больше не распространён

А как же initramfs?

костыль.

костыль.

cpio и/или initramfs ?

tar vs cpio

http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html

костыль.

cpio и/или initramfs ?

и то и другое.

Ты совсем дебил, что-ли?

Я же сразу сказал что работает, а что не работает.

find ... | xargs tar -cf --- это не работает (если tar запустится >1 раза), а ты, как всегда влез и пернул, что оно работает как надо.

Ты совсем дебил

наверное. УМВР, ЧЯДНТ?

ты, как всегда влез и пернул, что оно работает как надо.

тащем-то это ты влез и пёрнул, что у тебя что-то там не работает, и как всегда не смог объяснить, что именно.

tar

В игнор укурка! Сри в мозг самому себе.

Объяснили же:

Пока там один тар запущен, всё «работает». Как только будет больше одного тара, всё сломается. Освежить память на предмет «когда именно будет больше» можно из man xargs (конкретно на линуксе по умолчанию - когда наберётся имён файлов на 128KiB).

С нетерпением жду комментария «ну никто же в здравом уме не будет 128К на вход, оно же большое, не разводите помоек и много файлов не нужно, а так всё работает».

и вам того же, и вас туда же.

Как только будет больше одного тара, всё сломается.

зачем запускать сразу два tar'а?

С нетерпением жду комментария «ну никто же в здравом уме не будет 128К на вход, оно же большое, не разводите помоек и много файлов не нужно, а так всё работает».

не дождёшься.

tar достаточно.

rar

нешвабодно

швабодолюбители уже выехали за тобой

tar, 7-Zip вполне неплох.

Как только будет больше одного тара, всё сломается.

ты вроде-бы адекватный, потому объясню, почему у тебя ломается: просто tar делает всё записями по 512 байт. Всё, кроме маленьких архивов. Потому и ломается, если всё это пихать по 1 файлу в stdout, как вы зачем-то делаете.

вот например так можно:

$ rm -f z.tar; tar -rf z.tar a.txt; tar -rf z.tar b.txt; tar -tvvf z.tar
-rw-r--r-- drb/users         6 2014-02-19 13:34 a.txt
-rw-r--r-- drb/users         6 2014-02-19 13:29 b.txt

Нет ты :)

Напоминаю, что было n комментов назад. Ты предложил конструкцию find ... | xargs tar -cf - | gzip для архивации всех файлов, которые нашёл find.

Она работает (с виду!) для небольшого количества файлов, но сломается, когда их имён будет настолько много, что xargs будет (ПОСЛЕДОВАТЕЛЬНО) запускать несколько tar'ов (когда имена не уместятся в 128КБ). Не только у нас сломается, а у тебя сломается. Прямо вот твоя команда, которую ты написал и заверил, что она работает.

Как она должна бы работать? xargs запускает tar на первую пачку файлов, вывод tar'а отправляется gzip'у. Потом xargs запускает tar на вторую пачку файлов, вывод нового tar'а отправляется тому же gzip'у. Таким образом мы получаем два и более tar-архивов, объединённые (как если бы мы следали два tar-файла и над ними учинили cat) и сжатые gzip.

Не работает она потому, что у tar есть явный маркер конца архива. Когда ты добавляешь файл к существующему архиву (как tar -rf z.tar b.txt в том сообщении, на которое я отвечаю), этот маркер конца перезаписывается новыми элементами. А вот когда несколько tar-архивов объединяются (например, как в твоей команде find | xargs ... в том случае, если файлов много), мы имеем на выходе tar с маркером конца архива, к которому дописан ещё tar с маркером конца архива и т.д.. Если мы распакуем такой «составной» tar с помощью обычной команды tar, он остановится на первом же маркере конца архива. (Его можно распаковать полностью, но другим способом).

Формат tar не выделяет «маленькие архивы» и всегда работает с записями по 512 байт. Т.е. ключевой момент — именно объединенине нескольких выводов tar'а в один stdout. Так делает твоя команда при достаточном количестве файлов. Тебе приводили примеры, которые делают при небольшом количестве файлов то же самое, что твоя команда делает при большом. Специально приводили примеры, которые ломаются точно так же, как сломается твой, но которые можно проверить, не создавая файлов с общей длиной имён на 128КБ. Тестовые примеры, которые предназначены для того, чтобы иллюстрировать неработающее, а не для того, чтобы работать.

Я бы выбрал другой тестовый пример: в ТВОЕЙ конструкции find ... | xargs tar -cf - | gzip добавить для xargs параметр -n1, получилось бы find ... | xargs -n1 tar -cf - | gzip. Запакуй так более одного файла — и распакуется только один (хотя весить выходной архив будет как для всех). Дело в том, что архив «маленький», скажешь ты? Так возьми два больших файла, всё равно сломается. Дело в том, что «маленький» архив это где мало файлов, а не где мало данных, скажешь ты? Ну тогда сдаёмся: создавай столько файлов, чтобы имена не поместились в 128КБ, и наблюдай, как твоя команда просто так берёт и перестаёт работать.

Напоминаю, что было n комментов назад. Ты предложил конструкцию find ... | xargs tar -cf - | gzip для архивации всех файлов, которые нашёл find.

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

По этой причине IRL в моихз скриптах написано так:

LIST=$(mktemp)
find ... >$LIST
tar -cf $ARCHIVE
gzip $ARCHIVE

причём после каждой команды я проверяю $?.

А в данном случае, да, я ошибся, tar --create создаёт один архив, и конечно на второй раз получится ерунда. Тут нужен tar --append (который не совместим с выводом в stdout естественно, как и с --gzip).

Не работает она потому, что у tar есть явный маркер конца архива.

нету там никакого маркёра, просто нулей напихано.

маркер конца перезаписывается новыми элементами.

не, просто нулей не добавили, вот такая ерунда и получается. Почитай про многотомные tar-архивы. Там как раз правильные куски делаются. Но просто tar --create конечно том тебе не сделает.

Т.е. ключевой момент — именно объединенине нескольких выводов tar'а в один stdout.

я согласен с этим.

Дело в том, что архив «маленький», скажешь ты? Так возьми два больших файла, всё равно сломается

потому-что там должны быть нули, а их и нет. Можешь сам проверить с помощью hexdump. Я уже посмотрел.

Ну тогда сдаёмся: создавай столько файлов, чтобы имена не поместились в 128КБ, и наблюдай, как твоя команда просто так берёт и перестаёт работать.

эта? Да, признаю, это я ошибся. Просто я никогда так не делаю, а делаю по очереди. А если делать параллельно, то там у тебя не только эти баги появятся, но и множество других.

А это ничего что вместе с mkisofs ты заодно получаешь ограничение её FS, длина имени файлов, уровни вложенности каталогов, только базовые атрибуты ?

man iso9660 level3. А атрибуты мне не нужны дома

man iso9660 level3. А атрибуты мне не нужны дома

открой для себя /dev/loop, и узнай, что ВНЕЗАПНО можно сделать ФС из любого файла. Причём *любую*, а не только 9660. Может FAT тебе больше понравится?

tar + xz

7z

без сжатия tar, со сжатием 7z,bpzip2 - всеми ядрами жмут

таром жму.

Тар не жмёт, а архивирует. А gzip — жмёт. Ваш К.О.

А я zip использую. (тот, который не gzip)

Хотя в консоли tar -czf на уровне подсознания уже :)

А атрибуты мне не нужны дома

И где это указано в вопросе ? Телепатов тренируешь ?

ARJ

Tar же!