Настоятельно просим вас при общении соблюдать Правила форума и законы РФ. Наша тематика вне политики, поэтому воздержитесь от обсуждения ситуации на Украине и связанных с ней событий, независимо от того, какую сторону вы поддерживаете.
Также напоминаем, что наш форум находится в доменной зоне .ru, физически расположен на российских серверах и мы соблюдаем действующее законодательство России. Любые сообщения о политике будут удаляться.
Linux Forum → Общие вопросы → Вопрос по созданию zip-архива
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Нужно создать zip-архив включив в него все файлы, каталоги и подкаталоги, исключая указанные каталоги.
Как создать архив со всей структурой разобрался:
zip -r vse.zip *А вот как запретить при этом архивацию каталога например по имени images, то есть чтобы в архиве vse.zip было все, кроме images?
man zip точно знает.
Читать в районе ключика -x.
Спасибо работает.
Сразу уточню как исключить несколько каталогов - может кому-то пригодится.
Еще такой вопрос: а как отключить сжатие вообще, то есть задача собрать просто все файлы в 1 архив.
Если кому-то непонятно, зачем это нужно я объясню.
Например стоит задача перенести большое количество файлов и каталогов с одного компьютера в интернете на другой максимально быстро. Можно начать перелив пофайлово, но придется очень долго лить, гораздо быстрее упаковать, перенести 1 файл (линейная скорость передачи будет очень высокой) и распаковать на месте. При этом zip-архив меня в первую очередь интересует как инструмент упаковки в 1 файл, а сжатие меня не интересует, упаковка/распаковка шла бы гораздо быстрее, если не сжимать.
Я что-то никак не могу разобраться какой ключ задать, чтобы zip не сжимал данные.
Связка из tar+gzip представляется более целесообразной.
Касательно вопроса: man zip на предмет ключа -Z, --compression-method.
задача перенести большое количество файлов и каталогов с одного компьютера в интернете на другой максимально быстро.
всё уже придумано до нас:
File: tar.info, Node: Applications, Next: looking ahead, Prev: backup, Up: operations
4.6 Notable `tar' Usages
========================_(This message will disappear, once this node revised.)_
You can easily use archive files to transport a group of files from one
system to another: put all relevant files into an archive on one
computer system, transfer the archive to another system, and extract
the contents there. The basic transfer medium might be magnetic tape,
Internet FTP, or even electronic mail (though you must encode the
archive with `uuencode' in order to transport it properly by mail).
Both machines do not have to use the same operating system, as long as
they both support the `tar' program.For example, here is how you might copy a directory's contents from
one disk to another, while preserving the dates, modes, owners and
link-structure of all the files therein. In this case, the transfer
medium is a "pipe":$ (cd sourcedir; tar -cf - .) | (cd targetdir; tar -xf -)
You can avoid subshells by using `-C' option:
$ tar -C sourcedir -cf - . | tar -C targetdir -xf -
The command also works using long option forms:
$ (cd sourcedir; tar --create --file=- . ) \
| (cd targetdir; tar --extract --file=-)or
$ tar --directory sourcedir --create --file=- . \
| tar --directory targetdir --extract --file=-This is one of the easiest methods to transfer a `tar' archive.
Если "максимально быстро через Интернет", то можно ещё сжимать с помощью xz.
Пётр.
Если "максимально быстро через Интернет", то можно ещё сжимать с помощью xz.
можно.... tar -cJ
Вот только на практике у меня получилось медленнее, да ещё и народ возмутился - памяти мало 
Пришлось вернуть bzip2.
Peter пишет:Если "максимально быстро через Интернет", то можно ещё сжимать с помощью xz.
можно.... tar -cJ
Вот только на практике у меня получилось медленнее, да ещё и народ возмутился - памяти мало
Пришлось вернуть bzip2.
Я имел в виду только время пересылки. Памяти xz вроде бы действительно требует больше,
а скорость работы зависит от опций. На глаз работает быстро, но я не сравнивал xz и bzip2
по скорости работы.
Пётр.
Памяти xz вроде бы действительно требует больше,
а скорость работы зависит от опций. На глаз работает быстро, но я не сравнивал xz и bzip2
по скорости работы.
я сравнивал. Памяти xz не только много забирает, он её ещё и использует, причём совершенно случайным образом (о кешах можно забыть). А bzip2 - очень древняя программа, и потребляет мало памяти, даже с -9. Ну и скорость соответственно у bzip2 обычно намного быстрее. А сжатие немного хуже. Но это совсем не однозначно. На практике возможно и по другому.
В любом случае - бывает, что время сжатия сильно превышает время загрузки. (особенно если учесть толщину сегодняшних каналов, и тот факт, что bzip2 уже подходит почти вплотную к пределу сжатия).
Сейчас проверил на каталоге с подкаталогами и оказалось в точности так, как Вы говорите.
Размер tar - 281690K, bzip2 работал 1m29s, размер архива - 130177K,
xz за 2m52s создал архив размером 128328K.
Однако на небольшом архиве с проектом на Qt xz сжал каталог вдвое лучше, чем zip.
Пётр.
Однако на небольшом архиве с проектом на Qt xz сжал каталог вдвое лучше, чем zip.
именно zip?
bzip2 это совершенно особый, уникальный архиватор.
Peter пишет:Однако на небольшом архиве с проектом на Qt xz сжал каталог вдвое лучше, чем zip.
именно zip?
bzip2 это совершенно особый, уникальный архиватор.
Да, именно zip. Размер tar - 102400, zip - 28248, bzip2 - 13248, xz - 12344,
т.е. и здесь разница невелика.
Пётр.
Размер tar - 102400, zip - 28248, bzip2 - 13248, xz - 12344,
ну zip это LZ78, как и gzip. 1978й год был очень давно...
ну zip это LZ78, как и gzip.
не совсем, zip - lz78
gzip - deflate (lz с плюшками )
правда по эффективности практически не отличаются
не совсем, zip - lz78
gzip - deflate (lz с плюшками )
ох... Это всё интересно только олдфагам 
правда по эффективности практически не отличаются
они и в принципе ничем не отличаются 
Много мелких файлов лучше всего переносить rsync`ом wink
bzip2 сжимает большинство файлов эффективнее, но медленнее, чем более традиционные gzip или ZIP. В этом отношении он похож на другие современные алгоритмы сжатия.
http://ru.wikipedia.org/wiki/Bzip2#.D0. … 1.82.D1.8C
Вот сейчас стоит задача максимально быстро упаковать на одной системе и распаковать на другой 150 тысяч файлов. Сжатие не интересует вообще. Нужно использовать минимум процессора и памяти, чтобы не подвисать систему. Не могу определится что использовать zip (с опцией -0) или tar. Визуально скорость tar что-то не понравилась - долго почему-то пакует и распаковывает, кажется zip гораздо быстрее - да и какой-никакой прогресс показывает пусть в виде хотя бы распакованных файлов.
Подскажите что выбрать.
bzip2 сжимает большинство файлов эффективнее, но медленнее
нет. алгоритм конечно занимает какое-то время, но и чтение/запись - тоже. Пока мы не запишем, нам нельзя считать, потому если скорость записи низкая (а она низкая), то каким-бы не была скорость сжатия, тормозить процесс будет не она. Потому на практике скорость сжатия часто не влияет на общую скорость. Мы не можем писать быстрее, однако можем писать меньше, сжав архив. По этой причине часто сжатие даёт увеличение скорости, а вику пишут недоучки.
Хотя конечно всё зависит от CPU и количества памяти. Если вы используете xz -9 на третьем пне, то конечно жать он у вас будет неделями. Но bzip2 довольно древний архиватор, и на компах моложе 7 лет обычно даёт ускорение.
кажется zip гораздо быстрее
случайные флуктуации. С чего он будет быстрее, да ещё и "гораздо"? Наверное просто архив оказался рядом с данными или типа того.
drBatty, мне сжимать вообще не надо, а bzip2 как я понял только сжимает. Поэтому вопрос выбора между tar и zip. Вот не знаю что выбрать - 150 тысяч файлов - операция нелегкая. Может это вообще стоит на группы как-то файлы разбить - только как чтобы автоматом.
Задача перелить 150 тысяч файлов с одного сервера на другой. Если лить скажем filezill'ой пофайлово - то это будет очень долго. Если делать tar --gzip - вешает систему.
drBatty, так все таки что бы вы порекомендовали для даной задачи: упаковать 150 тысяч файлов (упаковка может быть медленной и ресурсоемкой - это будет делаться на компьютере, на котором нагрузка меня не волнует) и распаковать - здесь уже мне нужна минимальная нагрузка на систему - особенно процессор. Чем воспользоваться, никак не могу определится.
Уточню задачу - распаковать с минимальным потреблением ресурсов - пусть это будет даже долго, главное чтобы минимально грузило процессор. При этом упаковка не особо интересует - может быть и ресурсоемкой. Есть какой-то оптимальный выход?
valet,
операция распаковки в случае gzip/bzip2 по ресурсам -- это семечки в сравнении с записью распакованного на диск, всё упрётся в производительность дисковой подсистемы.
Сжатие поможет экономить а) ресурсы диска/время при записи/чтении запакованного или б) трафик/время при передаче по сети.
По поводу загрузки процессора -- есть nice/renice для понижения приоритета.
А в остальном, возьмите тестовый блок в несколько Gb да и проверьте, как оба/три/больше вариантов (включая rsync) поведут себя в ваших условиях.
всё упрётся в производительность дисковой подсистемы.
это конечно печально, подозреваю что в это я и не вписываюсь со своими 150 тысяч файлов.
б) трафик/время при передаче по сети.
это да - но этот вопрос меня абсолютно не интересует - согласен даже передать намного больше, если нужно. Да и экономия при сжатии там сомнительная так как это jpg-файлы.
а) ресурсы диска/время при записи/чтении запакованного
ну не знаю, насколько я понимаю - все равно же надо перед записью распаковать - на что потратятся пусть маленькие ресурсы, но потратятся, а записываться будет все равно в результате такого же размера файл - где экономия? Или я что-то не так понимаю?
есть nice/renice для понижения приоритета.
спасибо за наводку - буду гуглить...
Нашел способ для моего случая, запощу тут - может кому-то пригодится:
-n 19 - самый меньший проиритет (для процессора)
-с 3 - режим Idle для операций ввода/вывода (для диска)
И система будет работать отлично, так как мой tar будет использовать ресурсы так сказать бережно и только в том случае если другие процессы их не используют.
А кстати чистый nice без ionice не решает проблемы - ну это как я понял связано с тем, что тут говорили - сложность в дисковых операциях чтения/записи...
Всем спасибо за помощь. Особая благодарность bormant за наводку на nice.
мне сжимать вообще не надо, а bzip2 как я понял только сжимает. Поэтому вопрос выбора между tar и zip.
вы читать умете?
сжатие даёт увеличение скорости,
вы читать умете?
А вы?
Я кажется это тоже прокомментировал:
ну не знаю, насколько я понимаю - все равно же надо перед записью распаковать - на что потратятся пусть маленькие ресурсы, но потратятся, а записываться будет все равно в результате такого же размера файл - где экономия? Или я что-то не так понимаю?
Если мое утверждение верно, то сжатие никак не может давать увеличение скорости. Пусть будет очень незначительное уменьшение по скорости, но оно будет.
1. Распаковка сжатого содержимого: разжать и записать оригинал
2. Распаковки несжатого - только записать оригинал.
Как может быть увеличение в первом случае? Разве я не прав?
В общем случае сжатое/несжатое содержимое берутся из откуда-то. Экономия вот на этом "откуда-то" -- на чтении с диска, на приёме из сети.
Но поскольку ранее уже было сказано, что исходники в JPEG, то есть практически несжимаемые данные, то в этом контексте сжатие/распаковка ничего, кроме нагрузки на процессор, не даст.
ps. Хорошей иллюстрацией могла бы быть FIDO mailbomb -- практически нет затрат на передачу огромного файла, передать такого размера файл одним куском нереально (в то время).
bormant, сейчас для большинства fidonet непонятное что-то...
ну не знаю, насколько я понимаю - все равно же надо перед записью распаковать - на что потратятся пусть маленькие ресурсы, но потратятся, а записываться будет все равно в результате такого же размера файл - где экономия? Или я что-то не так понимаю?
Если мое утверждение верно, то сжатие никак не может давать увеличение скорости. Пусть будет очень незначительное уменьшение по скорости, но оно будет.
ваше утверждение верно, но только в том случае, если у вас информация сжимается из памяти в память. Если сжатие происходит на диск, то очевидно, что скорость создания архива в любом случае не выше скорости записи. В силу того, что запись с прошлого века производится НЕ процессором, то этот процессор очевидно будет простаивать. Т.е. мы можем его нагружать, причём довольно сильно. Ну а время записи прямо пропорционально размеру - запишем в 2 раза меньше == вдвое быстрее.
1. Распаковка сжатого содержимого: разжать и записать оригинал
ваша ошибка в том, что разжатие идёт потоком, т.е. непрерывно и одновременно с записью. Например bzip2 жмёт блоками в ~1Мб. Т.е. если ваш архив будет больше Мб, то разжатие будет осуществляться вместе с записью. А не перед нею.
newzenon, На самом деле такую гадость можно не только в FIDO сделать. Просто в FIDO это впервые(?) появилось. Суть:
1. создаём разрежённый файл из одних нулей скажем в 50Тб. Он у нас занимает на диске совсем немного.
2. добавляем его аттачем к письму.
3. по дороге он упаковывается
4. а у принимающей стороны распаковывается. Но уже не как разряжённый.
Эффект - система умирает, ибо нет места.
И все таки без сжатия быстрее распаковывается. Создал 5 относительно небольших tar'ов по 200 Мб в среднем и запустил распаковку - сделало за несколько секунд. Потом все удалил перепаковал с сжатием и запустил распаковку - делало несколько минут.
Так что это какие-то сказки что с сжатием быстрее распаковывается.
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Linux Forum → Общие вопросы → Вопрос по созданию zip-архива
Форум работает на PunBB, при поддержке Informer Technologies, Inc
