Заголовок и структура формата tar

Question

У меня есть проект для школы, который подразумевает создание c-программы, которая работает как tar в системе unix. У меня есть несколько вопросов, которые я хотел бы кто-нибудь объяснить мне:

1. Размерность архива. Я понял (из просмотра в Интернете), что в архиве определено число блоков по 512 байт. Таким образом, заголовок имеет 512 байт, затем за ним следует содержимое файла (если это только один файл для архивации), организованный в блоках из 512 байт, а затем еще 2 блока по 512 байт.

   Например: предположим, что у меня есть файл txt из 0 байтов для архивации. Это должно означать несколько 512 * 3 байта для использования. Почему, когда я работаю с функцией tar в unix и свойствах click, он имеет 10.240 байт? Я думаю, что он добавляет некоторые 0 (NULL) байтов, но я не знаю, где и почему и сколько ...

2. Заголовок chcksum. Как я знаю, это должен быть размер архива. Когда я проверяю его с помощью hexdump -C, он кажется рядом с реальным размером (при нажатии свойств) архива. Например, 11200 или 11205 или что-то подобное, если я архивирую 0-байтовый txt-файл. Является ли этот размер восьмеричным или десятичным? Мои ставки - это восьмеричные, потому что вся информация, которую вы помещаете в заголовок, должна быть в восьмеричном. Мой второй вопрос на этом этапе - это то, что добавлено больше от исходного размера 10240 байт?

3. Режим заголовка. Предположим, что у меня есть файл с 664, файл формата будет 0, тогда я должен поместить в заголовок 0664. Почему в подлинном архиве печатается еще 3 0 в начале (000064)?

Answer 1

Существуют различные версии формата tar, и не все расширения предыдущих форматов всегда совместимы друг с другом. Поэтому всегда есть немного угадывания. Например, в очень старых Unix-системах имена файлов не позволяли иметь более 14 байтов, поэтому пространство для имени файла (включая путь) было много; позже, с более длинными именами файлов, он должен был быть расширен, но не было места, поэтому имя файла было разделено на 2 части; еще позже gnu tar ввел псевдо-символические ссылки @@ LongLink, которые заставили бы старые деревья по крайней мере восстановить исходное имя файла.

1) Тар изначально был * T * ape * Ar * chiver. Чтобы обеспечить постоянную подачу на кассеты и избежать слишком много старта/остановки ленты, необходимо сразу написать несколько блоков. 20 Блоки по 512 байт были по умолчанию, а опция -b - установить количество блоков. Очень часто этот размер был заранее определен аппаратным обеспечением и использовал неправильные блокирующие факторы, что сделало ленту непригодной для использования. Вот почему tar добавляет \ 0-заполненные блоки, пока размер tar не будет кратен размеру блока.

2) Размер файла находится в восьмеричном формате и содержит истинный размер исходного файла, который был помещен в tar. Он не имеет никакого отношения к размеру файла tar. Контрольная сумма рассчитывается из суммы байтов заголовка, но затем сохраняется и в заголовке. Таким образом, действие хранения контрольной суммы изменит заголовок, тем самым аннулирует контрольную сумму. Вот почему вы сначала сохраняете все другие поля заголовка, устанавливаете контрольную сумму в пробелы, затем вычисляете контрольную сумму, а затем заменяете пробелы своим расчетным значением.

Обратите внимание, что заголовок смоченного файла является чистым ascii. Таким образом, в те старые времена, когда tar-файл (компоненты которого были простым ascii) получил поврежденный, администратор мог просто открыть файл tar с помощью редактора и восстановить компоненты вручную. Вот почему дизайнеры tar-формата боялись \ 0 байтов и использовали пробелы.

3) Тарные файлы могут хранить блокирующие устройства, персональные устройства, каталоги и т. Д. Unix хранит эти режимы файлов в том же месте, что и флаги разрешений, а режим файла заголовка содержит полный файл , в том числе бит типа файла. Вот почему число больше, чем чистое разрешение.

Существует много информации на странице http://en.wikipedia.org/wiki/Tar_%28computing%29.