Библиотека для работы с tar-архивами.

libtar не смотрел?

единственная найденная мной библиотека для работы с tar'ом написана на haskell

libtar на сях же, явно больше на виду, нежели хаскеле-биндинг

Любопытно. А как у неё с переносимостью?

И правда, слона не приметил. Но она находится только по запросу libtar, а хаскелёвый tar я в своё время зачем-то прицельно искал.

посмотрел в арче: pacman -Ss «\btar\b» вполне выводит 6 результатов, 4ый сабж, чуть ниже haskell-tar.

libarchive

Плюсую libarchive. Давно с этой библиотекой работал, остался очень доволен. Умеет всё на свете, работает быстро, api чистый и понятный. Очевидно, с С++ так же дружит.

libarchive

Тот же вопрос: что с переносимостью? Кроме того там насколько я понял лицензия различается от файла к файлу.

Идеальный метод: прочитать http://en.wikipedia.org/wiki/Tar_(file_format) и написать самому. Это ж tar, а не rar.

Хочется писать и читать tar из программы на C++. Вызывать внешний tar или использовать исходники GNU tar не хочется.

слушай, там формат тупой до примитивности:

1. заголовок - структура со всякой хренью (имя и т.д.)

2.1 первые 512 байт файла

...

2.9001 последние 512 байт фала дополненные нулями

Затем впритык тоже самое для след. файла.

Вот и всё. Ну есть ещё костыль для сохранения длинных (>100 байт) имён файлов.

Вот скажи, о какой либе ты спрашиваешь?

facepalm.jpg

Ребята, вы умом тронулись? Давайте так: каждый из тех, кто тут предлагает «написать самому», в течении часа сам пишет распаковщик, без ошибок и со всеми фичами, что предлагает libarchive (совместимость разных версий, имена файлов и т.п.), и предоставляет на суд общественности.

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

Ребята, вы умом тронулись? Давайте так: каждый из тех, кто тут предлагает «написать самому», в течении часа сам пишет распаковщик, без ошибок и со всеми фичами, что предлагает libarchive (совместимость разных версий, имена файлов и т.п.), и предоставляет на суд общественности.

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

а мне нужно только чтение архива

ТСа не читай @ сразу отвечай? Пишет же: «Хочется писать и читать tar».

причём с коротким именем файла. Причём одной конкретной версии

Небось файл этот был сферический, и в вакууме...

Вас вот так вот кто-нибудь всерьез послушает, и навелосипедит...

А когда потребуется поддержка еще чего-нибудь (сжатия например), навелосипедит свою обкладку вокруг zlib. Да так неэффективно, что... А потом костыликами прикрутит и xz. Ладно, я думаю, всё понятно...

ТСа не читай @ сразу отвечай? Пишет же: «Хочется писать и читать tar».

tar вообще не поддерживает запись, только добавление. А добавление реализуется тривиально.

Вас вот так вот кто-нибудь всерьез послушает, и навелосипедит...

в соседнем треде я уже писал, что случаи разные бывают. А навелосипедит - невелика беда. Я в своё время тоже std::string написал, и ничего - жив ещё. Хотя IRL я этот свой string никогда и нигде не применял.

tar вообще не поддерживает запись, только добавление. А добавление реализуется тривиально.

Добавление это уже не запись? Шок.

А добавление реализуется тривиально.

Ну хоть что-нибудь изобразите уж. Запись, чтение, ну тривиально же?

Вот вам мой пример действительно тривиального кода. http://people.freebsd.org/~kientzle/libarchive/man/archive_read.3.txt , раздел example. А если заменить _open на _open_filename, то вообще будет ~5 строк кода.

Я в своё время тоже std::string написал ... никогда и нигде не применял.

Зачем тогда писать было? Для обучения? Похвально. Не стали использовать? Почему? Наверное по той же причине, почему я и не советую писать свой libarchive, а взять уже готовый, ага?

Добавление это уже не запись? Шок.

ага. Есть запись, а есть добавление. В EXT3/4 можно запретить запись, но разрешить только добавление (append only). Это вообще разные режимы открытия фалов. Это Linux, детка.

Ну хоть что-нибудь изобразите уж. Запись, чтение, ну тривиально же?

что тут изображать-то?

fread(&header, sizeof(header), 1, arch);
fread(&data_buf, 512, size_b, arch);

вот и всё чтение файла в память. Записывается(в смысле добавляется) точно так же.

Вот вам мой пример действительно тривиального кода. http://people.freebsd.org/~kientzle/libarchive/man/archive_read.3.txt , раздел example. А если заменить _open на _open_filename, то вообще будет ~5 строк кода.

а у меня - две (:

Да и вообще - вы ещё либу для доступа к plain-text'у напишите (:

Зачем тогда писать было? Для обучения?

не... Хотелось быстрее. Получилось. Раза в три примерно. Но... Не пригодилось. Так иногда бывает...

Наверное по той же причине, почему я и не советую писать свой libarchive, а взять уже готовый, ага?

моё решение - один из вариантов. у него тоже есть преимущества. и недостатки.

Поддерживаю поддержавших libarchive

Есть какие-нибудь варианты?

кроме упомянутого libarchive есть такой уровень абстракции как VFS фреймворков . tar должен по идее поддерживаться всеми «из коробки»- потому что прост как полено.

Кстати, а почему tar? а не 7z например, у которого есть компрессия..

В EXT3/4 можно запретить запись

Причем тут это? ТС явно просил запись, в том смысле, чтобы взять и создать тар и записать его куда-нибудь. Это правда так сложно понять из текста автора?

Вы хотите развести демагогию по поводу терминологии? OK. append-only файл открывается в write-mode, вас это не смущает? А, то, что вы используете write() с O_APPEND, тоже не смущает? Может вы путаете добавление в конец, и добавление в произвольную позицию? Обе эти операции (сюрприз) называются записью.

что тут изображать-то?
fread(&header, sizeof(header), 1, arch);

Вы так шутите? Нет уж, вы пожалуйста аналог-то изобразите. Просто прочитать файл в память это вовсе не прочитать tar-архив. Просто для примера, вы контрольные суммы считать не собираетесь? Будете мусор за tar-архив принимать? Браво.

А покажите как вы будете транслировать флаги файлов tar-архива в mode_t? В две строчки уложитесь? А точно правильно напишите?

Вы же сами сказали, задача чрезвычайно тривиальная: всего-то *правильно* прочитать tar-архив. Не абы-как, с кучей «а вот тут оно споткнётся», а правильно. Пока что у вас даже на словах не получается.

не... Хотелось быстрее. Получилось. Раза в три примерно.

Покажите?

Вы хотите развести демагогию по поводу терминологии?

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

Вы так шутите? Нет уж, вы пожалуйста аналог-то изобразите. Просто прочитать файл в память это вовсе не прочитать tar-архив.

именно это и называется «прочитать tar». Вот такой во это странный «формат».

Просто для примера, вы контрольные суммы считать не собираетесь?

нет. А что тут такого? Почему tar (GNU tar) 1.26 контрольную сумму не считает, а я её должен считать? Что не верим? Проверяйте. Отлично всё распаковывается, и выдаёт $? == 0.

Будете мусор за tar-архив принимать? Браво.'

gnu tar'у можно, а мне нельзя?

А покажите как вы будете транслировать флаги файлов tar-архива в mode_t? В две строчки уложитесь? А точно правильно напишите?

что за флаги-то? Мне они не нужны. А нужны они нашему ТСу?

Вы же сами сказали, задача чрезвычайно тривиальная: всего-то *правильно* прочитать tar-архив. Не абы-как, с кучей «а вот тут оно споткнётся», а правильно. Пока что у вас даже на словах не получается.

а оно и получается «правильно», но только в моём ЧАСТНОМ случае. А вот остальные случаи меня таки и не волнуют. В отличие от авторов библиотек. Поймите простую вещь - мне не нужен ПОЛНЫЙ функционал, мне достаточно ЧАСТИ. И моя часть реализуется парой строчек.

Покажите?

что там показывать-то? Всё в точности так же как и с tar'ом - реализован только лишь нужный функционал. Кроме того, шаблоны я не использовал вообще в принципе. А зачем мне шаблоны, если этот класс используется только в производных классах?

gnu tar'у можно, а мне нельзя? .... почему tar (GNU tar) 1.26 контрольную сумму не считает, а я её должен считать? Что не верим? Проверяйте.

~$ cat /dev/urandom | tar x
tar: This does not look like a tar archive
tar: Skipping to next header

(Из этого маленького примера, вы, кстати, сможете понять, почему именно важно проверять контрольную сумму?)

Вот вам код:

http://git.savannah.gnu.org/cgit/tar.git/tree/src/buffer.c#n372

tar_checksum(). check_compressed_archive(), но на самом деле вызывается для проверки любых таров:

http://git.savannah.gnu.org/cgit/tar.git/tree/src/buffer.c#n693

что за флаги-то? Мне они не нужны. А нужны они нашему ТСу?

Омг. Вы зачем тогда тар-архив «читали»? Ради хохмы? Флаги нужны, чтобы понять, что за файл. Очевидно же, ну. Хотя, да, по вашему сообщению вижу, что вам ничего от тар архива было не нужно. Тогда вопрос задам напрямую: что именно вы делали с тар архивом, если вы с ним ничего не делали?..

Может в этом скрывается ваше иллюзорное восприятие тривиальности работы с таром? Вы просто ничего не делали с ним?

Вы меня не поняли. ...

Я всё прекрасно понял, вы просто развели демагогию. Перечитайте свой ответ на то, что где сказал, что нужна запись. И что потом, вы вдруг встряли со своим «ложки нет», когда об этом речи вообще не шло. Никогда вообще в этом треде не говорил про запись в середину, вы что-то себе там сами додумываете.

что там показывать-то? Всё в точности так же как и с tar'ом - реализован только лишь нужный функционал.

Да хоть бы ваш «нужный функционал» посмотреть, проверяете ли граничные случаи... ах, вам же не нужно. Ясно. И строки у вас строго сферические. Ну понятно.

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

Из этого маленького примера

из приведённого вами примера понятно что /dev/urandom не генерит с налёту правильный заголовок tar и по терверу можно пождать когда-же наконец прискочат правильные 512 байт. Больше ничего пример не говорит

Вот вам код

а вы сам-то код смотрели, или спецификацию ? проверяется арифметическая сумма(даже не crc) 504 байт заголовка, и ничего более. И никакого отношения к данным файла она не имеет.

drBatty для своих целей набросал пару несложных функций а-ля «прочесть из tar»,«дописать в tar» - какие там нах. граничные случаи ?? частое решение частной задачи. И не думаю, что для себя любимого он не проверил mode и разумную допустимость прочих полей заголовка. Кстати реализовать аналогичные функции - вполне разумный совет ТСу, если тот пишет в embeded и будет потом экономить каждый байт.

http://libarchive.github.com/

Works on most POSIX-like systems (including FreeBSD, Linux, Solaris, etc.)
Supports Windows, including Cygwin, MinGW, and Visual Studio. 

Reads a variety of formats, including tar, pax, cpio, zip, xar, lha, ar, cab, mtree, rar, and ISO images.
Writes tar, pax, cpio, zip, xar, ar, ISO, mtree, and shar archives. 

из приведённого вами примера понятно что /dev/urandom не генерит с налёту правильный заголовок tar и по терверу можно пождать когда-же наконец прискочат правильные 512 байт. Больше ничего пример не говорит

Пример говорит о том, что у меня в ~ не создалось куча рандомного мусора. Вероятность такого поведения есть, но вы сможете посчитать эту вероятность при checksum + всех sanity checks? Тар проверяет кучу значений.

Тут уже гигабайт 20 обработалось, и всё что выдало:

tar: Archive contains `\343\304\nhJp\300Tl\313uU' where numeric off_t value expected
tar: Archive contains `\270\034\331E\005\032Q\255' where numeric mode_t value expected
tar: Archive contains `cfv\317\020+HE"D\262' where numeric time_t value expected
tar: Archive contains `\004\0\312\020\006"\020;' where numeric uid_t value expected
tar: Archive contains `_e\033\027=\227F' where numeric gid_t value expected
tar: Archive contains `\004\0\312\020\006"\020;' where numeric uid_t value expected
tar: Archive contains `_e\033\027=\227F' where numeric gid_t value expected
?rwsrwsrwt 4294967295/4294967295 18446744073709551615 1969-12-31 15:59 =\362\260\rI\214\256 unknown file type `e'
tar: Skipping to next header

Ни одного файла пока не создано.

проверяется арифметическая сумма(даже не crc) 504 байт заголовка

Так это именно то, что нужно. Еще раз, при отсутствии всех этих проверок в tar, cat /dev/urandom | tar x закончился бы мусором, который бы вы разгребали долго-долго. Tar не обязан проверять данные, но свой же формат заголовков — обязан и проверяет.

вполне разумный совет ТСу, если тот пишет в embeded и будет потом экономить каждый байт.

Правильный совет для «среднего» embedded: взять libarchive, и если не влезает, добавить configure флагов, которые бы могли его урезать. Таким образом вы получаете маленький но все еще оттестированый код. И, возможно, еще поможете сообществу.

Совсем хардкорный эмбеддед тут иррелевантен, но сводиться к тому-же.

Я не вижу ни одного применения для подхода drBatty или Sadler. Разве, что лицензия не public domain у libarchive.

частое решение частной задачи

В том то и дело, что не решение. Это мина замедленного действия.

И еще раз почитайте, что именно товарищи писали. Библиотеки исключалась как подход:

«слушай, там формат тупой до примитивности: ... Вот скажи, о какой либе ты спрашиваешь?» (c) drBatty «Идеальный метод: прочитать http://en.wikipedia.org/wiki/Tar_(file_format) и написать самому. Это ж tar, а не rar.» (c) Sadler

Библиотеки исключались ТС'ом, ибо «некросплатформенно» или «лицензия не та». Логичный выход. Так что увянь, чтоб я больше от тебя здесь уведомлений не видел.

Библиотеки исключались ТС'ом, ибо «некросплатформенно» или «лицензия не та»

Это ваши влажные фантазии. Я (как и любой, кто захочет прочитать тред) тут лишь видел, что ТС задавал вопросы по поводу переносимости и лицензии, никаких исключений не было. Более того, ТС рассматривал вариант брать GNU'тый код, а посему BSD-лицензия (под которой идет libarchive) трижды подходит.

Вы не читаете вопрос на который отвечаете, потом даете глупые (даже вредительские) советы, при этом ваш разговор идет в гопник-стиле. Это чудесным образом описывает степень вашей профессиональной квалификации.

nuff said

Пример говорит о том, что у меня в ~ не создалось куча рандомного мусора

наиболее вероятный случай - битый архив. Эмулируем :

dd bs=512 count=19 if=/dev/zero of=./thefile.bin
cp -f ./thefile.bin ./original.bin
tar cf thefile.bin.tar ./thefile.bin
(dd bs=512 count=1 if=./thefile.bin.tar; dd bs=512 count=19 if=/dev/urandom) | tar x
cmp thefile.bin original.bin

совет для «среднего» embedded: взять libarchive, и если не влезает, добавить configure флагов, которые бы могли его урезать. Таким образом вы получаете..

таким образом мы получаем 5 метров исходников, содержащих 99% ненужного нам функционала, и которые вынужденны будем поддерживать(в полном объёме) на своей embeded платформе, опционально ещё делая к ним ОО обёртку (напомню у ТС C++). В рамках поставленной в топике задаче,по критерию трудозатраты+надёжность это решение проигрывает drBatty,Sadler

Я не вижу ни одного применения для подхода drBatty или Sadler

Присмотрись. Это жизнь, детка.

(Из этого маленького примера, вы, кстати, сможете понять, почему именно важно проверять контрольную сумму?)

вы бредите:

$ echo "абвгдеф" > 1.txt
$ tar -cf 1.tar 1.txt
$ hexdump -C 1.tar
00000000  31 2e 74 78 74 00 00 00  00 00 00 00 00 00 00 00  |1.txt...........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 30 30 30 30  36 34 34 00 30 30 30 31  |....0000644.0001|
00000070  37 35 30 00 30 30 30 30  31 34 34 00 30 30 30 30  |750.0000144.0000|
00000080  30 30 30 30 30 31 37 00  31 32 30 32 30 36 31 34  |0000017.12020614|
00000090  30 32 33 00 30 31 31 31  32 31 00 20 30 00 00 00  |023.011121. 0...|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 75 73 74 61 72 20 20  00 61 72 61 6e 65 69 00  |.ustar  .aranei.|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 75 73 65 72 73 00 00  |.........users..|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  d0 b0 d0 b1 d0 b2 d0 b3  d0 b4 d0 b5 d1 84 0a 00  |................|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002800
$ sed -i 's/д/Ц/' 1.tar 
$ hexdump -C 1.tar
00000000  31 2e 74 78 74 00 00 00  00 00 00 00 00 00 00 00  |1.txt...........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 30 30 30 30  36 34 34 00 30 30 30 31  |....0000644.0001|
00000070  37 35 30 00 30 30 30 30  31 34 34 00 30 30 30 30  |750.0000144.0000|
00000080  30 30 30 30 30 31 37 00  31 32 30 32 30 36 31 34  |0000017.12020614|
00000090  30 32 33 00 30 31 31 31  32 31 00 20 30 00 00 00  |023.011121. 0...|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  00 75 73 74 61 72 20 20  00 61 72 61 6e 65 69 00  |.ustar  .aranei.|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 75 73 65 72 73 00 00  |.........users..|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  d0 b0 d0 b1 d0 b2 d0 b3  d0 a6 d0 b5 d1 84 0a 00  |................|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002800
$ tar -xf 1.tar
$ cat 1.txt
абвгЦеф

Омг. Вы зачем тогда тар-архив «читали»? Ради хохмы? Флаги нужны, чтобы понять, что за файл. Очевидно же, ну.

а оно надо ТСу? Лично мне это было не надо. Мне надо было прочитать простой регулярный файл с заданным именем. ВСЁ.

Тогда вопрос задам напрямую: что именно вы делали с тар архивом, если вы с ним ничего не делали?..

см. выше. я файл прочитал.

Да хоть бы ваш «нужный функционал» посмотреть, проверяете ли граничные случаи..

вот это как раз и есть «демагогия». Какие ещё вы придумаете «граничные условия»? Если ваша либа умеет считать контрольную сумму - я рад за вашу либу. Мой код да, не считает. Но ведь и gnu tar тоже не считает! А то, что подсунув ему заведомый мусор, вы получаете ответ - это мусор, дык что тут странного?

И строки у вас строго сферические. Ну понятно.

см. выше конкретику.

Контрольная сумма и оттестированность кода чем-то помогли ?

Вы не понимаете разницу между данными, которые несет архив (payload) и контрольной информацией? Я уже сказал: payload не считается таром, и не должен. А контрольная информация в хедере обязана считаться, чтобы обеспечить хоть какой-то уровень «sanity». Она и считается.

Вот вам пример: у вас побился linux-3.0.tar.bz2, все сместилось на пару байт. Вы счастливо делаете tar xjf linux-3.0.tar.bz2, после чего обнаруживаете тысячи файлов с бинарными названиями у себя в ~. Это нормальное поведение? Адекватные люди, в том числе разработчики GNU tar и libarchive, скажут что нет. Ну а вы можете спорить...

таким образом мы получаем 5 метров исходников, содержащих 99% ненужного нам функционала, и которые вынужденны будем поддерживать(в полном объёме)

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

Если вам так не хочется тащить весь libarchive, вытащите от туда файлы, функции. Лично я бы такой подход не приветствовал, но такая практика тоже есть, и это имело бы хоть какой-то смысл.

по критерию трудозатраты+надёжность это решение проигрывает drBatty,Sadler

Голословное утверждение. Чтобы так формально сравнивать, аж по критериям, то нужны будут конкретные цифры. А коль их нет, то придется оперировать здравым смыслом.

велосипед drBatty это конечно-же плохо

никто не спорит. В большинстве случаев надо применять готовый код. Но до маразма доходить тоже не надо. Если код для вызова функции либы занимает 5 строк, а сама реализация - 2 строки, то нах нужна _тут_ либа?

sed -i 's/д/Ц/' 1.tar

Вы издеваетесь? Как о стену горох... Не данные. Тару нет дело до того, что именно внутри лежит, поэтому он и не считает что там. А вот контрольная сумма для хедера служит для других целей, которые я описал выше.

Ну постарайтесь же включить логику.

Лично мне это было не надо.

Ладно, это уже пошло по второму кругу. В свое время вам ничего не было нужно. Я это вижу в таком ракурсе: вы как-то научились считать «2+2», и теперь всем подряд советуете выбросить калькуляторы, потому что на листочке считать «тривиально же!». Я вижу это именно так.

Считать 2+2 действительно тривиально, я тут спорить не буду.

Это чудесным образом описывает степень вашей профессиональной квалификации.

Какая задача, такое и решение. А моя квалификация - не твоего ума дело.

linux-3.0.tar.bz2

Плохой пример. Возьмем таки backup.tar, без сжатия. ;-)

Я уже сказал: payload не считается таром, и не должен. А контрольная информация в хедере обязана считаться, чтобы обеспечить хоть какой-то уровень «sanity». Она и считается.

если вам это надо - посчитайте. Я не против. Перед тем, как расковырять свой tar, я проверял GnuPG подпись данного файла. Т.ч. я УВЕРЕН в целостности этого файла. И дополнительная проверка - это не нужный оверхед.

Вы издеваетесь? Как о стену горох... Не данные. Тару нет дело до того, что именно внутри лежит, поэтому он и не считает что там. А вот контрольная сумма для хедера служит для других целей, которые я описал выше.

Это вы издеваетесь: мне пофиг до заголовков, и до тара, мне нужно СОДЕРЖИМОЕ.

Давайте по простому: я даю сыну конфету. Он её разворачивает, и съедает. И ему пофиг, что фантик надорван. И он на дату изготовления не посмотрел. Он вообще читать ещё не умеет. А вы предлагаете вызвать тётю Дусю, доцента РАН, кафедра общественного питания. Ибо только она грамотно развернёт фантик, проверит его целостность, и срок годности. За одно проверит, откуда папа нашёл деньги на конфетку, и заплатил ли он НДС и прочее.

Ладно, это уже пошло по второму кругу. В свое время вам ничего не было нужно

мне и сейчас ничего не нужно. И вам не нужно доводить до маразма.

Считать 2+2 действительно тривиально, я тут спорить не буду.

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

если вам это надо - посчитайте. Я не против. Перед тем, как расковырять свой tar, я проверял GnuPG подпись данного файла.

Я всё думал, что же мне эта беседа напоминает. Вспомнил:

http://www.mediascan.by/index.files/oem2010.files/image001.jpg

ТС спросил про библиотеку для работы с tar'ом, но ему начали рассказывать про какие-то узко-направленные, специфичные, я бы даже сказал уникальные задачи, при этом в полном отрыве от контекста, и выдавать это за «идеальные» варианты решения изначальной проблемы.

Вот вам пример: у вас побился linux-3.0.tar.bz2backup.tar, все сместилось на пару байт. Вы счастливо делаете tar xjf backup.tar, после чего обнаруживаете тысячи файлов с бинарными названиями у себя в ~

не обнаружу..даже если физически вырежу проверку контрольной суммы заголовков. Вы же не читаете исходники, на которые ссылаетесь:)

не обнаружу..даже если физически вырежу проверку контрольной суммы заголовков. Вы же не читаете исходники, на которые ссылаетесь:)

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

Я говорю про чтение архива «в лоб», как предлагают товарищи велосипедисты. Тот вариант безопасен?

Самому интересно стало... Вы про это?

 for (p = magic + 2; p < magic + NMAGIC; p++)
    if (memcmp (record_start->buffer, p->magic, p->length) == 0)
      return p->type;

Ну я что-то сомневаюсь, что это входило в план велосипедистов. ;-)

(плюс, судя по хедерам, magic нету в старых архивах.)

Хотя, мимо. В данном случае, magic это zip magic. Но я вижу, что tar'овский magic проверяется при decode header. Но всё таки, уточните что же именно вы имели ввиду.

ТС спросил про библиотеку для работы с tar'ом

ТС просил

писать и читать tar из программы на C++

учитывая тривиальность «формата», я и предложил альтернативное решение (ибо в топике выше уже были ссылки на либы).

но ему начали рассказывать про какие-то узко-направленные, специфичные, я бы даже сказал уникальные задачи, при этом в полном отрыве от контекста, и выдавать это за «идеальные» варианты решения изначальной проблемы.

передёргиваете. Я ничего толком не знаю про задачу ТС, но у меня был случай, когда такое выдёргивание было оптимальным вариантом. Хотя конечно чаще встречаются случаи, когда нужно воспользоваться библиотекой. Но про библиотеки уже написали до меня.

Я говорю про чтение архива «в лоб», как предлагают товарищи велосипедисты. Тот вариант безопасен?

вариант, когда GNU/Tar читает данные без проверки контрольной суммы безопасен? Тупая арифметическая сумма, для которой 2+3==3+2 безопасна? CRC32 из WinRAR'а безопасна? Нет, нет, и ещё раз - нет. Все эти варианты опасны. Да и вообще - это не проблема архиватора. Если вам нужно проверить целостность файла - используйте GnuPG, а не изобретайте велосипед. А то у вас опять получится винрар.

tar'овский magic проверяется при decode header.

если вам будет спокойнее - вы можете его проверить. Я не запрещаю.

CRC32 из WinRAR'а безопасна? Нет, нет, и ещё раз - нет. Все эти варианты опасны. Да и вообще - это не проблема архиватора. Если вам нужно

CRC32 для нескольких сотен байт хедера вполне так неплохое решение. А хедер это единственное что волнует, когда речь идет о безопасности архива.

Но и у тара тоже все OK: там еще и поля в ascii обязаны быть. Это доп проверка на ошибки: с точки зрения отделения мусора от реального архива, tar-формат очень и очень неплох.

Я не буду сравнивать с crc32 и т.д., но для повседневных решаемых задач он, что называется, «good enough».

проверить целостность файла - используйте GnuPG

Обычный tar со всеми своими стандартными проверками вполне подходит для 99.9(9)% задач архивации и вполне безопасен. Велосипедное решение же подходит для 0.00(0)% + 1 задачи (именно вашей), при этом при всем имеет кучу других минусов (например шаг влево, шаг вправо — сегфолт/надо дописать/еще раз задебагить/немного зарефакторить/и еще куча всего ...).

Вы где-то велосипедите, а где-то по воробьям из пушки палите. Есть же здравый смысл. При наличии нескольких великолепных библиотек, «писать свой тар» в здравый смысл никак не входит, имхо. А уж коль речь пошла о gpg-подписях, то о каких-то накладных расходах на проверку tar-хедера речи вообще не идет — по сравнению с gpg, расходы на проверку tar стремятся к 0. Где логика? Снова не вижу ни одного «за» использовать свой велосипед, даже (или тем более) в вашей задаче.

CRC32 для нескольких сотен байт хедера вполне так неплохое решение. А хедер это единственное что волнует, когда речь идет о безопасности архива.

там разве CRC32? Да и CRC32 можно с лёгкостью подделать. Да и это совсем не единственное. Да и вообще, никого не волнуют ваши хидеры, волнуют именно данные.

Но и у тара тоже все OK: там еще и поля в ascii обязаны быть. Это доп проверка на ошибки

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

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

уважаемый, поймите простую вещь: мне НЕ НУЖНО отделять мусор от архива. Я и так знаю, что это архив. Если вы этого не знаете - то это У ВАС какой-то особый, уникальный случай.

Обычный tar со всеми своими стандартными проверками вполне подходит для 99.9(9)% задач архивации и вполне безопасен.

вы не понимаете простейших вещей: подделать этот ваш тарбол может любой школьник. А проверки валидности данных, которые прошли например через сеть, оставьте пожалуйста другим инструментам. Например если это TCP/IP, то там есть своя проверка своей КС. Которая прекрасно отлавливает ошибки в этом своём TCP. И их отлично исправляет. Ваша проверка - дополнительный и не нужный (в библиотеке и в коде) оверхед.

Велосипедное решение же подходит для 0.00(0)% + 1 задачи (именно вашей), при этом при всем имеет кучу других минусов (например шаг влево, шаг вправо — сегфолт/надо дописать/еще раз задебагить/немного зарефакторить/и еще куча всего ...).

не надо ничего дебагить - что там дебагить в двух-то строчках? а целостность данных проверяется в несколько ином месте. Не надо её проверять ещё раз.

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

а я и не предлагаю «писать свой тар». В этом вашем таре 95% кода, который никак не связан с «читать и писать файлы из тарбола». К примеру это создание/распаковка инкрементальных бекапов двух видов, многотомные архивы, и много другое. Тех же форматов тара AFAIK намного больше одного. Библиотека и сам tar обязаны всё это поддерживать, а мой велосипед - не обязан. Потому он простой как кирпич, и такой же надёжный.

А уж коль речь пошла о gpg-подписях, то о каких-то накладных расходах на проверку tar-хедера речи вообще не идет — по сравнению с gpg, расходы на проверку tar стремятся к 0. Где логика?

вот и я говорю - где логика? Зачем тянуть 100500 строк кода с совершенно ненужными проверками, если мы уже притянули 100500 кода, с ещё более лучшими и долгими проверками? Зачем тянуть поддержку формата, который уже 20 лет никто не юзает? Для совместимости? С чем? Если мой код обязан по ТЗ работать лишь с теми архивами, который сам же и делает? В принципе он может работать и с POSIX'вым tar'ом, как на вход, так и на выход, но с каким-то startar, о котором только одфаги помнят, работать он не может. А оно надо?

Снова не вижу ни одного «за» использовать свой велосипед, даже (или тем более) в вашей задаче.

мой велосипед быстрее и проще. И с этим не поспоришь. Да, там нет некоторого функционала, но он и не нужен.

судя по хедерам, magic нету в старых архивах

нету..но в планы велосипедистов и не входила поддержка старых архивов. Ровно как и multivolume. Так же как и извлечение файлов из архива в файловую систему. Весь упомянутый в треде велоспед - (найти и)прочитать регулярный файл из tar`а в память и (создать заголовок и)записать данные из памяти в tar.

Я говорю про чтение архива «в лоб», как предлагают товарищи велосипедисты. Тот вариант безопасен?

более чем. Самодельная функция а-ля «int gnutar_seek_to_name(int tar,char *filename,struct stat *)» даже без привлечения libtar реализуется быстро, кратко и потокобезопасно. И кто сказал, что «чтение в лоб» обязательно исключает проверку сумм и сигнатур заголовков ?

ТС спросил про библиотеку для работы с tar'ом, но ему начали рассказывать про какие-то узко-направленные..

вообще-то ТС-у сказали, что если функционал требуется небольшой, то написать его самому дело совсем несложное - ненадо этого бояться. Это вы начали упирать что tar это мегасложно, вряд-ли кто тут мог его осилить, что любой велосипед зло, что чтение архивов из /dev/random - рядовое дело и тут без библиотеки с поддержкой мыслимых форматов не обойтись.