хрен знает я регулярно жму файл размером 100G (дамп винта) gzip-ом, на мой взгляд лучшее решение по скорость/коэфф сжатия

А я жму в основном индексированные картинки и тексты.
Так вот, когда жмешь текст, лучше всего жмет rar, не отстает от него
tar.bz2, а вот gzip или zip жмут хуже. Особенно это видно на
картинках. Информация для восстановления в zip вообще не знаю
для чего делалась, а rar восстанавливает.
Кстати, rar на данный момент лучший архиватор. Плотнее не жмет никто.

А насчет того, что все zip понимают. Звонит американец - типа надо
кое-какие документы ему отправить, потому как заехать за ними
он не может. Ладно, жму все в zip, отправляю. Чел перезванивает
и просит отправить ему все пофайлово, так как он не знает, что такое
zip и как его распаковывать.

P.S. winrar понимает tar.bz2 и tar.gz Часто вместо линуксового я
его использую, запущенным из-под wine.

tar+gzip - да.
tar+bzip2 - не обязательно :) вследствие блочности bzipа можно,если знать размеры 
затареных файлов и параметров tar, вычислить номер bzip-блока, с которого начинается 
нужный файл, и разворачивать начиная с него. Для этого действительно нужно написать
 пару скриптов. Работать будет не всегда(проблемы с потоковой обработкой). Но будет.

Пример(неоптимально, c ошибками и с кучей ограничений - но демонстрирует уровень 
сложности данной задачи). Размер блока bzip2 должен быть кранен блоку tar-а(далее 
TarBlockSize). Нужно сделать 1 изменение в программе bzip2 - добавить вывод на stderr 
строки с размером зажатого блока. Что тривиально. Затем:

ALaZip() {
  tar cjvvf "$@" &>/tmp/filelist
  tar rjf "$1" /tmp/filelist 2>&1 \
    | awk '/^[0-9]+$/ {sum+=$1; print sum}' \
    | tail -n 1 >/tmp/listsize
  tar rf $1 /tmp/listsize
}

UnALaZip() {
  $arch=$1 ; shift
  size=`du -b $arch | cut -f 1`
  dd if=$arch skip=$((size-TarBlockSize)) \
    | tar xvf $archive tmp/listsize \
    && dd if=$arch skip=$((size-TarBlockSize-$(cat tmp/listsize))) \
    | tar xjvf $arch tmp/filelist \
    || { tar xjvf $arch "$@" ; return ; }
  needNext=0
  needThis=0
  blockstart=0
  while read mode owner size date time file ; do
    case $mode in
      [0-9]*) # это размер зажатого блока от bzip2
        test $needThis = 1 && dd if=$arch skip=$blockstart count=$mode
        needThis=$needNext
        needNext=0
        blockstart=$blockstart+$mode
      *)
        needFile "$file" "$@" && needThis=1 && needNext=1 || needNext=0
    esac
  done <tmp/filelist | tar xjvf - "$@"
}

2anonymous (*) (2003-01-27 21:54:01.836): на сидюках механизм восстановления работает на ура, просто у каждого механизма восстановления свой запас прочности... И кроме того он был орентирован на восстановление audio, а там некоторая эээ... неполнота восстановления вполне допустима. :)

anonymous (*) (2003-01-28 01:07:59.412)
pipe под виндами РА-БО-ТА-ЕТ! То что он не работает в cygwin (и прогах им портированных) - проблема _исключительно_ цигнуси. Портируйте с помощью SFU3 и Ваши волосы будут мягкими и пушистами. :) Да, еще рекомендую забыть про 9х...

arj-gzip

Явный спор о фкусе устриц с теми, кто их ел. Человек, приученный к tar, bzip2, split,cat - прелесетй arj не поймёт. Воспитание другое. Скажу о вкусностях:

автоопределение оставшегося места при многотомности - кому никогда и ничего не надо на дискеты писать - тот молодец.

Возможность восстановить файлы с серединного куска многотомного архива - она есть далего не во всех комбинациях tar+gz

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

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

возможность получить оглавление без распаковки и чтения всего архива (актуально на медленных каналах и устройствах) - tar нужно распаковать весь, целиком. Для архива в 100 гиг - все 100 гиг. Нормальным это может считать только человек, который не видел иных решений.

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

Обновления архива - тоесть замена файлов в архиве. типа инкрементальной архивации.
u: Update files (new + newer)
u1: Update files (new + OLDER)
u2: Update files (new + different)
u3: Update files (new + CRC mismatch)

поиск текстовой строки в архиве (разницу между грепом в выводе тара тоже надо объяснить, или сами поймёте?)

переименование файла внутри архива

произвольная степень интерактивности - от 0 до сообщения о каждом чихе.

Конечно, процентов 70-80 из его возможностей можно реализовать кучей скриптов вокруг tar+..z+split . Но как раз это никому не нужно :)

Лично я перестал использовать arj только по 2 причинам:
1. досовая версия не работает под win32 с длинными именами, а иной я не видел.
2. Последние лет 5 сижу в виндозном гуе - и нажать на папке правую ктопку и сказать "compress to zip" - покрывает 95% моих потребностей в архивировании.

а вот что касается вещей неинтерактивных - то на всех досово-виндозных автоматизированных и полуавтоматизированных задачах при возможности использую arj. Потому что жмёт сильнее или так же как zip, так же быстр + гора доп. фич, иногда полезных.

А из-за отсутствия arj на юниксах иногда приходится простейшие вещи делать через жопу. Или вообще не делать. Впрочем, большинство юниксойдов имеют полезное (для них) свойство мировоззрения - всё, чего они сделать не могут - то никому не надо. А кому надо - тот посто фишку не рубит, и вообще дурак.

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

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

>Явный спор о фкусе устриц с теми, кто их ел.

Кушали, как же. Продолжение ниже.

>автоопределение оставшегося места при многотомности - кому никогда и ничего не надо на дискеты писать - тот молодец.

А о том, что при записи на дискеты нужно сохранить некоторый объем информации, а не заполнить некоторый объем свободного места представление имеем?

>Возможность восстановить файлы с серединного куска многотомного архива - она есть далего не во всех комбинациях tar+gz

man tar, man gzip просветляет на предмет выбора нужной комбинации.

>ваш сплит поймёт, что ему части подсунули в другом порядке?

Человек явно не читал man split. А если и читал, то никогда не задумывался о практическом применении возможностей. Пример того, как можно перепутать при сборке cat'ом архива, порезанного split'ом в студию.

>а тар сможет понять, что ему подсунули не бутый архив, а только первую часть, и где-то должна быть вторая?

man split

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

Относительно проверки целостности: man md5sum. И встречный вопрос: а как arj может узнать, что он разархивирует именно тот архив, который был выслан?

>возможность получить оглавление без распаковки и чтения всего архива (актуально на медленных каналах и устройствах) - tar нужно распаковать весь, целиком.

man tar почитать конечно ломает. Прочитал три опции, заучил как их применять (даже не потрудившись подумать над их значением), и вообразил что на этом возможности tar'а заканчиваются.

>Нормальным это может считать только человек, который не видел иных решений.

А ты сам знаком с реальными альтернативами?

>огромное количество опций распаковки - типа только те, что уже есть, но старше. только те, что есть, но младше. Тех, что есть, но больше. Только те, кого нет. все, которые старше.

man tar, man gzip

>поиск текстовой строки в архиве (разницу между грепом в выводе тара тоже надо объяснить, или сами поймёте?)

ИМХО это тебе надо, но не объяснять, а для начала показать эту самую разницу.

>переименование файла внутри архива

Мануалы не читаем в принципе?..

>Конечно, процентов 70-80 из его возможностей можно реализовать кучей скриптов вокруг tar+..z+split . Но как раз это никому не нужно :)

Только ВНИМАТЕЛЬНОЕ прочтение man tar позволяет реализовать не меньше 60% перечисленных возможностей, а умелое использование стандартных инструментов Unix с избытком перекрывает их.

>а вот что касается вещей неинтерактивных - то на всех досово-виндозных автоматизированных и полуавтоматизированных задачах при возможности использую arj.

А теперь пожалуйста про всю прелесть использвания интерфейса командной строки в винде.

>А из-за отсутствия arj на юниксах иногда приходится простейшие вещи делать через жопу.

То есть пытаться решить задачу известным способом, не задумываясь о том, что в Unix ее можно решить иначе, причем проще и эффективнее.

>Впрочем, большинство юниксойдов имеют полезное (для них) свойство мировоззрения - всё, чего они сделать не могут - то никому не надо.

Ну-ка: чего нельзя сделать в Unix'е (при условии что располагаешь некоторыми знаниями и навыками)?

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

Относительно прочтения отдельного файла из архива - читайте документацию. Только прежде чем это делать, все же следует считать весь архив на HDD, и лишь затем извлекать конкретные файлы. Почему это так объяснять надо?

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

Лучше ли? Работа в досе и выньдоусе не научила пользоваться стандартными средствами Unix, такими как pipe, например?

преимущество arj в том, что множество несвязанных друг с другом вещей (компрессия, архивирование, избыточность, шифрация etc) заключены в один флакон.
Недостаток в том, что все эти функции реализованы на бытовом уровне.

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

Кстати пару лет назад пользовался arj32. Он понимает длинные имена.

У _arj_ перед rar нет никаких преимуществ.

Перед tаr & (bzip2|gzip) нет _никаких_ достоинств.

Тем не менее обидно, когда имея файл arj приходится думать,
как его разжать (и понеслать - досовый arj через wine: что-то открывается,
но не все, ошибки лезут... через dosemu - изврат).

2 anonymous (*) (2003-01-30 19:56:03.746)

>Перед tаr & (bzip2|gzip) нет _никаких_ достоинств.

Вы забыли добавить md5sum, split & cat.

2 jackill

>Тем не менее обидно, когда имея файл arj приходится думать, как его разжать

Воистину. Вот он, единственный действительно весомый аргумент в пользу arj.