Программа обработки архивов tar
         

Выполнение резервного копирования и обновления файлов

.* дамп
. + что такое дамп
. + разные уровни дампа
. - полный дамп = дамп всего
. - дамп уровня 1, 2 и т.д.
Уровень дампа n дампирует все измененное с уровня n-1
. + как использовать сценарии для дампа
. _ сценарии для выполнения после редактирования задания резервного
копирования (подробности)
. + Задания резервного копирования, что это такое


. - как настроить
. - точный текст сценария [/sp/dump/backup-specs]
. + Проблемы
. - rsh не работает
. - rtape не устанавливается
. - (другие?)
. + опция tar --imcremental
. + ленты
. - защита записи
. - типы носителей


. : размеры и виды, используемые для разных целей
. - файлы и ленточные метки
одна метка между файлами, две в конце
. - распололжение ленты
MT записывает две метки в конец, при записи одна из них стирается
- 152 -
Произвести резервное копирование системы - значит создать архивы,
содержащие все файлы системы файлов. Эти архивы можно затем
использовать для обновления нескольких или всех из этих файлов
(например, если диск ломается или файл случайно стирается). Резервные
копии систем файлов еще называются дампами.
9.1 Использование tar для выполнения полных дампов *
Полные дампы можно делать только тогда, когда другие люди или
программы не модифицируют файлы системы файлов. Если файлы
модифицируются, когда tar производит резервное копирование, их нельзя
сохранить в архиве, в этом случае вы бы не смогли их обновить, если бы
вам это понадобилось. (Немодифицированные файлы записываютсмя без
труда и не разрушают архив.)
Вы можете захотеть использовать опцию '--label=архивная_метка' для
того, чтобы дать архиву метку тома, так что вы можете сказать, каков
архив, даже если его метка выпала с ленты или случилось что-то в этом
роде.
Если вы не уверены, что система, которую вы дампируете, помещается в
одном томе, используйте опцию '--multi-volume'. Убедитесь, что у вас
на руках достаточно ленты для завершения резервного копирования.
Если вы хотите дампировать каждую систему файлов отдельно, вам нужна
опция '--one-file-system' ('-l'), для предохранения tar от пересечения
границ системы файлов при сохранении (под)каталогов.
В опции '--incremental' ('-G') нет необходимости, т.к. есть полная
копия всего в системе файлов, и полное восстановление из резервной
копии может быть произведено только на полностью пустой диск.
Если вы не торопитесь и доверяете программе tar (и вашим


лентам), очень удобно использовать опцию '--verify' чтобы убедиться,
что ваши файлы действительно дампированы. Это также определит случаи,
когда файл был модифицирован при архивации. К сожалению, не все
устройства (в том числе и картриджи) можно проверить.
- 153 -
'--listed-incremental=snapshot-файл' всегда требует аргумента имени
файла. Если файл не существует, установите нулевой уровень дампа,
создающий файл. Если файл существует, используйте этот файл для того,
чтобы увидеть, что изменилось.
'--incremental' ('-G')
FIXME: просмотреть это
'--incremental' работает с пошаговым резервным копированием старого
формата GNU.
Эта опция должна использоваться только при создании пошаговой
резервной копии системы файлов. При использовании опции
'--incremental' tar записывает в начале архива элемент для каждого
каталога, которым нужно оперировать. Элемент для каталога включает
список файлов каталога во время завершения дампирования и флаг для
каждого файла, показывающий, нужно ли его помещать в архив. Информация
используется при осуществлении полного пошагового обновления.
Заметьте, что эта опция заставляет tar создавать нестандартный
архив, который нельзя прочесть не-GNU версиями программы tar.
Если опция '--incremental' используется с '--list', то tar для
каждого каталога архива выдает список его файлов на время создания
архива. Эта информация подается в формате, в котором нелегко читать,
но который зато не является неоднозначным для программы: каждому файлу
предшествует 'Y', если этот файл присутствует в архиве, 'N', если файл
не включен в архив или 'D', если файл - каталог (и включается в
архив). Каждое имя файла заканчивается нулем. За последним файлом
следует дополнительный нуль и чистая строка, показывающие конец данных.
Если опция '--incremental' используется с '--extract', то когда
находится элемент каталога, все файлы, существующие в каталоге, но не
записанные в список архива, удаляются из каталога.
Это удобно, когда вы восстанавливаете поврежденную систему файлов из


- 154 -
пошаговой резевной копии: это сохраняет состояние системы файов тем,
которое получено после резервного копирования. Если вы не используете
'--incremental', система файлов, вероятно, наполнится файлами, которые
не должны больше существовать.
'--listed-incremental=snapshot-файл' работает с резервным
копированием формата GNU.
'--listed-incremental=snapshot-файл' действует как '--incremental',
но при использовании в сочетании с '--create' также заставляет tar
использовать файл "файл", содержащий информацию о состоянии системы
файлов во время последнего резервного копирования, чтобы определить,
какие файлы включить в создаваемый архив. Затем файл модифицируется
tar. Если файл "файл" не существует при задании этой опции, tar его
создает и включает все соответствующие файлы в архив.
Файл, являющийся независимым архивом, содержит дату своей последней
модификации, номер, список устройств и имена каталогов. tar архивирует
файлы с более поздней датой модификации или измененным временем,
каталоги с неизмененным номером и устройством, но измененным именем.
Файл модифицируется после того, как определяются файлы, подлежащие
архивированию, но перед тем, как создан новый архив.
9.2 Использование tar для выполнения пошагового дампа *
Выполнение пошагового дампа похоже на выполнение полного дампа, хотя
здесь обычно нужно больше опций.
Вам может понадобиться использовать опцию '-M' для приказа tar
хранить только те файлы, которые были модифицированы после указанного
date. date - дата и время последнего полного/пошагового резервного
копирования.
Стандартная схема - производить ежемесячный (полный) дамп - раз в
месяц, еженедельный дамп - раз в неделю.
Ниже приведена копия сценария, ичпользуемого для дампирования систем
- 155 -
файлов на машинах Free Software Foundation. Этот сценарий выполняется
через cron поздно ночью, , когда люди меньше любят сидеть за машинами.
Этот сценарий дампирует несколько систем файлов с нескольких машин


(через NFS). Оператор должен убедиться, что все машины завершили
работу ко времени, когда происходит дамп. Если машина ничего не
выполняет, ее файлы не дампируются и пошаговый дамп следующего дня не
сохраняет файлы, которые приходят для дампа.
#!/bin/csh
# Dump thingie
set now = 'date'
set then = ''cat date.nfs.dump'
/u/hack/bin/tar -c -G -v\
-f /dev/rtu20\
-b 126\
-N "$then"\
-V "Dump from $then to $now"\
/alpha-bits/gp\
/gnu/hack\
/hobbes/u\
/spiff/u\
/sugar-bombs/u
echo $now > date.nfs.dump
mt -f /dev/rtu20 rew
Вывод из этого сценария хранится в файле для того, чтобы оператор
позже мог его прочесть.
Этот сценарий использует файл 'date.nfs.dump' для хранения
даты/времени последнего дампа.
Т.к. это поточное ленточное устройство, не делается попыток
проверять архив. Это также объясняет высокий блочный фактор. Ленточное
устройство быть перемотано с помощью команды mt после того, как
произведен ламп.
9.3 Пошаговые опции *
- 156 -
'--incremental' ('-G') используется в сочетании с '--create',
'extract' или '--list' при резервном копировании и обновлении системы
файлов. Архив нельзя извлечь, и нельзя составить список его членов с
помощью опции '--incremental', если он был создан не с помощью опции.
Эта опция должна использоваться только сценарием, а не пользователем,
и обычно безотносительно к опции '--listed-incremental=snapshot-файл',
которая описывается ниже.
'--incremental' в сочетании с '--create' заставляет tar записывать в
начало архива элемент каждого каталога, который будет архивироваться.
Элемент для каталога включает список всех файлов каталога во время,
когда архив создан, и флаг для каждого файла, показывающий, нужно ли
его заносить в архив.
Заметьте, что эта опция заставляет tar создавать нестандартный
архив, который нельзя прочесть не-GNU версиями программы tar.
'--incremental' в сочетании с '--extract' заставляет tar читать
список содержимого каталога, сохраненный в архиве, удалять файлы


системы файлов, которые не существуют в их каталогах, когда архив был
создан, и затем извлекать файлы в архив.
Это удобно, когда вы восстанавливаете поврежденную систему файлов из
пошаговой резевной копии: это сохраняет сотояние системы файов тем,
которое получено после резервного копирования. Если вы не используете
'--incremental', система файлов, вероятно, наполнится файлами, которые
не должны больше существовать.
При использовании '--incremental' в сочетании с '--list' tar для
каждого каталога архива выдает список его файлов на время создания
архива. Эта информация подается в формате, в котором нелегко читать,
но который зато не является неоднозначным для программы: каждому файлу
предшествует 'Y', если этот файл присутствует в архиве, 'N', если файл
не включен в архив или 'D', если файл -каталог (и включается в архив).
Каждое имя файла заканчивается нулем. За последним файлом следует
дополнительный нуль и чистая строка, указывающие на конец данных.
'--listed-incremental=snapshot-файл' действует как '--incremental',
- 157 -
но при использовании в сочетании с '--create' также заставляет tar
использовать файл "файл", содержащий информацию о состоянии системы
файлов во время последнего резервного копирования, чтобы определить,
какие файлы включить в создаваемый архив. Затем файл модифицируется
tar. Если файл "файл" не существует при задании этой опции, tar его
создает и включает все соответствующие файлы в архив.
Файл, являющийся независимым архивом, содержит дату своей последней
модификации, номер, список устройств и имена каталогов. tar архивирует
файлы с более поздней датой модификации или измененным временем,
каталоги с неизмененным номером и устройством, но измененным именем.
Файл модифицируется после того, как определяются файлы, подлежащие
архивированию, но перед тем, как создан новый архив.
FIXME: этот раздел нужно записать.
9.4 Уровни резервного копирования *
Архив, содержащий все файлы системы файлов, называется полной


резервной копией или полным дампом. Вы можете застраховать свои
данные, каждый день получая полный дамп. Такая стратегия, однако,
требует много места на носителе и времени.
Более эффективно делать полный дамп только иногда. Чтобы
зарезервировать файлы между полными дампами, вы можете использовать
пошаговый дамп. Дамп уровня 1 архивирует все файлы, изменившиеся после
последнего полного дампа.
Обычная стратегия дампа - выполнять полный дамп раз в неделю, а дамп
уровня 1 - раз в день. Это значит, что некоторые версии файлов
фактически будут заархивированы более чем однажды, но эта стратегия
дампа возможна для обновления системы файлов с помощью извлечения
только двух архивов - последнего еженедельного (полного) дампа и
последнего ежедневного (первого уровня) дампа. Единственная
информация, которая теряется - файлы, измененные или созданные после
последнего ежедневного резервного копирования (Производить дамп чаще
одного раза в день обычно не стоит).
- 158 -
GNU tar работает с помощью сценария, который вы используете для
полного дампа и дампа первого уровня. Использование сценариев
(программ оболочки) для выполнения резервного копирования и
пересохранения - удобная и надежная альтернатива ручному набору
списков имен файлов и команд tar.
Перед использованием этих сценариев вам нужно отредактировать файл
'backup-specs', который задает параметры, используемые для сценариев
резервного копирования и сценария обновления.
FIXME: xref Script Syntax
Когда заданы параметры резервного копирования, вы можете выполнить
его или обновление путем выполнения соответствующего сценария.
Имя сценария обновления - restore. Имена сценариев резервного
копирования первого уровня и полного - level-1 и level-0. Сценарий
level-0 также существует под именем weekly, а level-2 - daily - эти
дополнительные имена можно изменить в соответствии с вашим планом
резервного копирования.
FIXME: xref Scripted Restoration
для получения информации о выполнении сценария обновления.


FIXME: xref Scripted Backups
для получения информации о выполнении сценария резервного копирования.
Пожалуйста, заметьте: сценарии резервного копирования и обновления
были созданы для использования вместе. Т.к. возможно обновлять файлы
вручную из архива, который был создан при использовании сценария
резервного копирования, и наоборот, создавать вручную архив, который
затем можно извлечь с помощью сценария обновления, легче использовать
сценарии.
- 159 -
FIXME: xref incremental
and listed-incremental
перед тем, как делать такую попытку.
FIXME: сократить названия подразделов
9.5 Задание параметров для резервного копирования и обновления *
Файл 'backup-specs' задает параметры резервного копирования для
сценариев резервного копирования и обновления, обеспечиваемых tar. Вы
должны отредактировать 'backup-specs' для соответствия с конфигурацией
вашей системы и планом при использовании этих сценариев.
FIXME: Написать о сценариях резервного копирования: BS -сценарий
оболочки... таким образом...'backup-specs' - в синтаксисе сценария
оболочки. Какой параметр... посмотреть сценарии резервного
копирования... которые нужно найти... сейчас синтаксис... значение
указывает на неубедительное...'backup-specs' задает следующие
параметры:
ADMINISTRATOR
Пользовательское имя администратора резервного копирования.
BACKUP_HOUR
Час, в который производится резервное копирование. Это может
быть число от 0 до 23 или строка 'now'.
TAPE_FILE
Устройство tar. Это устройство должно подключаться к машине,
на которой выполняются сценарии дампа.
FIXME: для всего привести примеры
TAPE_STATUS
Команда для получения состояния архивного устройства,
включая ошибки. На некоторых ленточных устройствах может не
- 160 -
быть такой команды, в этом случае просто используйте
'TAPE_STSTUS=false'.
BLOCKING
Блочный фактор, который tar использует при записи
дампированного архива.
FIXME: xref Blocking Factor
BACKUP_DIRS
Список систем файлов, подлежащих дампированию. Вы можете


включить в этот список имя каталога - включатся подкаталоги
этой системы файлов, безотносительно к тому, как они могут
выходить на другие сетевые машины. Подкаталоги других систем
файлов будут игнорироваться. Имя машины задает, на какой
машине выполнять tar
которая содержит систему файлов. Однако на этой машине
должен быть установлен GNU tar, и она должна иметь доступ к
каталогу, содержащему сценарии резервного копирования и их
файлы, использующие те же имена, что и на машине, на которой
выполняются сценарии (т.е. которые pwd будет печатать,
находясь в этом каталоге на этой машине). Если машина
содержит систему файлов, не имеющую такой возможности, вы
можете задать другую машину, так же, как доступ к системе
файлов через NFS.
BACKUP_FILES
Список отдельных файлов для дампирования. К ним должен быть
доступ с машины, на которой выполняется сценарий резервного
копирования.
FIXME: то же имя файла задать. через nfs...
9.5.1 Пример текста 'Backup-specs' *
Нижеприведенное - текст 'backup-specs', как он возникает в FSF:
# site-specific parameters for file systen backup.
- 161 -
ADMINISTRATOR=fridman
BACKUP_HOUR=1
TAPE_FILE=/dev/nrsmt0
TAPE_STSTUS="mts -t $TAPE_FILE
BLOCKING=124
BACKUP_DIRS="
albert: /fs/fsf
apple-gunkies:/gd
albert:/fs/gd2
albert:/fs/gp
geech:/usr/jia
churchy:/usr/roland
albert:/
albert:/usr
apple-gunkies:/
apple-gunkies:/usr
gnu:/hack
gnu:/u
apple-gunkies:/com/mailer/gnu
apple-gunkies:/com/archive/gnu"
BACKUP_FILES="/com/mailer/aliases /com/mailer/league *[a-z]"
9.5.2 Синтаксис 'Backup-specs' *
'Backup-specs' - в синтаксисе сценария оболочки. При редактировании
сценария рассматриваются следующие соглашения:
FIXME: "convention?"
Взятый в кавычки текст рассматривается как непрерывный, даже если он
состоит из более чем одной строки. Таким образом, вы не можете
включить текст, превращенный в комментарий, в многострочный, взятый в
кавычки. BACKUP_FILES и BACKUP_DIRS - два наиболее предпочтительных


параметра для этого.
Текст, взятый в кавычки, обычно не содержит wildcards. Однако
- 162 -
в 'backup-specs' параметры BACKUP_FILES и BACKUP_DIRS могут содержать
wildcards.
9.6 Использование сценариев резервного копирования *
Синтаксис выполнения сценария резервного копирования:
'script-name' [время_выполнения]
где время_выполнения - или заданное системное время, или now. Если вы
не задаете время, подразумевается время, заданное в 'backup-specs'.
FIXME: pxref Script Syntax
Вы должны начать сценарий с установления ленты или диска. Когда вы
начали сценарий, он запрашивает у вас, если нужно, новую ленту или
диск. Тома носителей не должны соответствовать архивным файлам -
многотомный архив может начинаться с середины ленты, которая уже
содержит конец другого многотомного архива. Сценарий restore выдает
приглашение носителю для тома архива, т.ч., чтобы избежать сообщения
об ошибке, вы должны запомнить, на какой дорожке лента или диск
содержит тот или иной том архива.
FIXME: xref Scripted Restoration
FIXME: изменились ли имена файлов?
Сценарии резервного копирования записывают два файла в систему
файлов. Первый - файл '/etc/tar-backup/', который используется
сценариями для хранения и извлечения информации о том, какие файлы
дампированы. Этот файл не предназначен для чтения людьми и не должен
быть ими удален.
FIXME: xref incremental and listed-incremental
для получения более подробной информации об этом файле.
- 163 -
Второй файл - файл протокола, содержащий имена систем файлов и
дампированных файлов, время, в которое время было произведено
резервное копирование, любые сгенерированные сообщения об ошибках и
сколько места осталось в томе носителя после того, как был записан
последний том архива. Вы можете проверять этот протокольный файл после
каждого резервного копирования. Имя файла -
'log-месяц-день-год-level-1' или 'log-месяц-день-год-full'.
Сценарий также выдает имя каждой системы, дампированной на
стандартный вывод.
FIXME: раздел о сценарии restore прокоментирован.

Форматы ввода даты

В этом разделе описываются текстуальные представления даты, которые
принимает GNU. Это строки, которые вы, как пользователь, можете
использовать как аргументы к разным программам. Интерфейс С (через
функцию getdate) здесь не описывается.
Хотя синтаксис даты здесь может представлять любое время с нуля
A.D., компьютерные целые числа недостаточно большие для такого
(сравнительно) долгого времени. Наиболее ранняя дата, разрешенная для
работы в системе Unix - полночь, 1 января 1970 UCT.
10.1 Общий синтаксис даты
Дата - строка, возможно пустая, содержащая много элементов,
разделенных пробелами. Пробел может быть опущен, если не может
возникнуть неоднозначность. Пустая строка означает начало этого дня
(т.е. полночь).


Порядок элементов несущественен. Строка даты может
содержать много объектов элементов:
* элементы календарной даты
* элементы времени суток
* элементы часового пояса
* элементы дня недели
* элементы отношения
* числа
Мы опишем каждый из этих типов элементов ниже.
Некоторые числа в большинстве случаев можно записать словами. Это
наиболее часто используется для задания элементов дня недели или
относительных элементов. Вот список:
first - 1
second - 2
third - 3
- 166 -
fouth - 4
fifth - 5
sixth -6
seven - 7
eighth -8
nine - 9
tenth - 10
eleventh - 11
twelfth - 12
last - -1
Когда месяц записан таким образом, он рассматривается, как будто
записан цифрами, это изменяет разрешенную строку.
В датах полностью игнорируется алфавитный принцип. Комментарии могут
быть заключены в круглые скобки, и эти скобки могут вкладываться одни
в другие. Слоги, не следующие за цифрами, игнорируются. Начальные нули
игнорируются.
10.2 Элемент календарной даты
Элемент календарной даты задает день года. Она задается по-разному,
в зависимости от того, как задается месяц: числами или буквами. Все
строки, приведенные ниже, задают календарную дату:
1970-9-17 # ISO 8601
70-9-17 # Век подразумевается по умолчанию
70-09-17 # Начальные нули игнорируются
9/17/72 # Общепринятая запись США
24 Septenber 1972
24 Sept 72 # Сентябрь имеет особое сокращение
24 Sep 72 # Трехбуквенные сокращения разрешены всегда
Sep 24, 1972
24-sep-72
24sep72
Год также можно пропускать. В этом случае используется последний
- 167 -
заданный год или текущий. Например:
9/17
sep 17
Правила.
Для месяцев, записываемых числами, разрешен формат ISO 8601
'год-месяц-число', где год - любое положительное число, месяц - число
от 1 до 12, а день - от 1 до 31. Если год меньше 100, к нему
добавляется 1990. Разрешена конструкция 'месяц/число/год', популярная
в Соединенных Штатах. И еще 'месяц/число', где пропускается год.
Месяцы, записываемые буквами, можно писать полностью: 'January',
'February', 'March', 'April', 'May', 'June', 'Jnly', 'August',


'September', 'October', 'November' или 'December'. Месяцы,
записываемые цифрами, могут сокращаться по первым трем буквам, за
которыми следует точка. Также можно писать 'Sept' вместо 'September'.
Когда месяцы записываются буквами, календарная дата может быть
задана так:
число месяц год
число месяц
месяц число год
число-месяц-год
Или, пропуская число:
месяц число
10.3 Элемент времени суток
Элемент времени дня задает время данного дня. Вот несколько
примеров, все из которых представляют одно и то же время:
20:02:0
- 168 -
20:02
8:02pm
20:02-0500 # B EST (Eastern U.S. Standard Time)
Чаще всего время суток задается 'часы/минуты/секунды', где часы -
число от 0 до 23, минуты - число от 0 до 59, а секунды - число от 0 до
59. Иногда секунды пропускаются, в этом случае им присваивается нуль.
Если за временем следует 'am' или 'pm' (или 'a.m.' или 'p.m.), час
может быть задан от 1 до 12, а минуты можно пропустить (им
присваивается 0). 'am' обозначает первую половину дня, 'pm' -вторую
половину дня. В этой записи 12 предшествует 1: полночь - '12am', а
полдень - '12pm'.
Время может иногда подвергаться коррекции по часовому поясу,
записанной как 'знак_часы_минуты', где знак - + или -, часы - число
часов пояса, а минуты - число минут пояса. Когда поправка на пояс дана
таким образом, она вызывает интерпретацию времени UTC, отменяя любое
предыдущее задание часового пояса или местного часового пояса. Минуты
можно умолчать, когда используется коррекция по часовому поясу. Это
единственный способ задания коррекции по часовому поясу с помощью
частей часа.
В поправке часового пояса могут быть заданы 'am' или 'pm', но не
одновременно.
10.4 Элемент часового пояса
Элемент часового пояса задает международный часовой пояс,
определяемый небольшим числом букв. Любой включенный период
игнорируется. Для обозначения часового пояса используется одна буква.
В элементе часового пояса могут быть представлены только полные часы.
Для получения информации о лучшем контроле за коррекцией часового


пояса см. предыдущий раздел.
Вот список часовых поясов, не сохраняющих дневной свет.
- 169 -
+000
'GMT' для Гринвича, 'UT' или 'UTC' для универсального
(координационного), 'WET' для Западной Европы и 'Z' для
войск.
+100
'WAT' для Западной Африки и 'A' для войск.
+200
'AT' для Азор и 'B' для войск.
+300
'C' для войск
+400
'AST' для Атлантического Стандарта и 'D' для войск.
500
'E' для войск и 'EST' для Восточного Стандарта.
+600
'CST' для Центрального Стандарта и 'F' для войск.
+700
'G' для войск и 'MST' для Горного Стандарта.
+800
'H' для войск и 'PST' для Тихоокеанского Стандарта.
- 170 -
+900
'I' для войск и 'YST' для Юконовского Стандарта.
+1000
'AHST' для Стандарта Аляска-Гаваи, 'CAT' для Центральной
Аляски, 'HST' для Гавайского Стандарта и 'K' для войск.
+1100
'L'' для войск и 'NT' для Нома.
+1200
'IDLW' для Международной Западной Линии и 'M' для войск.
-100
'CET' для Центральной Европы, 'FWT для Французской Зимы,
'MET' для Средней Европы, 'MEWT' для Среднеевропейской Зимы,
'N' для войск и 'SWT' для Шведской Зимы.
-200
'EET' для Восточной Европы, зоны 1 СССР и 'O' для войск.
-300
'BT' для Багдада, зоны 2 СССР и 'P' для войск.
-400
'Q' для войск и 'ZP4' для зоны 3 СССР.
-500
'R' для войск и 'ZP5' для зоны 4 СССР.
- 171 -
-600
'S' для войск и 'ZP6' для зоны 5 СССР.
-700
'T' для войск и 'WAST' для Западно-Австралийского Стандарта.
-800
'CCT' для Китайского Берега, зоны 7 СССР и 'U' для войск.
-900
'JST' для Японского Стандарта, зоны 8 СССР и 'V' для войск.
-1000
'EAST' для Восточно-Австралийского Стандарта, 'GST' для
Гвамского стандарта, зоны 9 СССР и 'W' для войск.
-1100
'X' для войск.
-1200
'IDLE' для Международной Восточной Линии, 'NZST' для
Новозеландского Стандарта, 'NZT' для Новой Зеландии и 'Y'
для войск.
Вот основные пояса DST:
0
'BST' для Британского Лета.
- 172 -
+400
'ADT' для Атлантического Дневного света.
+500
'EDT' для Восточного Дневного света.
+600
'CDT' для Центрального Дневного света.


+700
'MDT' для Горного Дневного света.
+800
'PDT' для Тихоокеанского Дневного света.
+900
'YDT' для Юконского Дневного света.
+1000
'HDT' для Гавайского Дневного света.
-100
'MEST' для Среднеевропейского Лета, 'MESC' для
Среднеевропейского Лета, 'SST' для Шведского Лета и 'FST'
для Французского Лета.
-700
'WADT' для Западно-Австралийского Дневного света.
- 173 -
-1000
'EADT' для Восточно-Австралийского Дневного света.
-1200
'NZDT' для Новозеландского Дневного света.
10.5 Элемент дня недели
Упоминание дня недели производится перед числом.
Дни недели можно записывать полностью: 'Sunday', 'Monday',
'Tuesday', 'Wednesday', 'Thursday', 'Friday' и 'Saturday'. Можно их
сокращать по первым трем буквам. Также разрешаются особые сокращения:
'Tues' для 'Tuesday', 'Wednes' для 'Wednesday' и 'Thur' или 'Thurs'
для 'Thursday'.
Число может предшествовать элементу дня недели. Лучше использовать
выражение типа 'third monday'. В этом контексте 'last день_недели' или
'next день_недели' тоже принимаются, происходит сдвиг на день назад
или вперед от дня_недели.
Запятая, следующая за днем недели, игнорируется.
10.6 Элементы отношения в строке даты
Элементы отношения сдвигают дату вперед или назад. Эффект элементов
отношения накапливается. Вот несколько примеров:
1 year
1 year ago
3 years
2 days
- 174 -
Единица перемещения во времени задается строкой 'day' или 'month'.
Это неопределенные единицы, т.к. имеют неравную продолжительность.
Более точные единицы - 'firtnight' - 14 дней, 'week' - 7 дней, 'day' -
24 часа, 'hour' - 60 минут, 'minute' или 'min' - 60 секунд, 'second'
или 'sec' - 1 секунда. Суффикс 's' в этих единицах принимается и
игнорируется.
Единице времени может предшествовать коэффициент, данный как
заданное число. Числа без знака рассматриваются как положительные.
Если нет множителя, подразумевается 1. Строка, за которой идет 'ago',
эквивалентна указанной единице времени без 1.
Строка 'tomorrow' значит текущий день + 1, 'yestesday' эквивалентно

Формат архивов TAR

11.1 Стандартный формат *
Архивный файл tar содержит серию записей. Каждая запись содержит
RECORDSIZE байт. Хотя этот формат имеет место при пользовании
магнитной лентой, часто используются и другие носители.
Каждый заархивированный файл представлен заглавием, описывающим


файл, за которым может следовать какое-то число записей, дающих
содержание файла. В конце архивного файла может быть запись, состоящая
из двоичных нулей, и маркер конца файла. Разумная система должна
записывать нули в конец, но такая запись не предполагается при чтении
архива.
Записи могут быть разбиты на блоки для физических операций I/O.
Каждый блок из n записей (где n задана с помощью опции
'--block-size=512-размер') записывается посредством операции 'write
()'. На магнитных лентах результат этого - отдельная запись на ленте.
При записывании архива последний блок записей должен быть записан в
полном размере, и его запись должна состоять из одних нулей. При
чтении архива разумная система должна иметь дело с архивами, последний
блок которых короче остальных или который содержит ненужную информацию
после нулей.
Заголовок определен в C (см. ниже). В GNU tar это часть файла
'src/tar.h':
/* Standard Archive Format - Standard TAR - USTAR. */
/* Header block on tape.
Здесь мы используем традиционные названия DP. "block" - большая
часть материала I/O. "record" - кусок информации, с которой мы имеем
дело. Обычно много "record" помещается в "block". */
#define RECORDSIZE 512
- 177 -
#define NAMSIZ 100
#define TUNMLEN 32
#define TGNMLEN 32
#define SPARSE_EXT_HDR 21
#define SPARSE_IN_HDR 4
struct sparse
{
char offset[12];
char numbytes[12];
};
union record
{
char charptr[RECORDSIZE]
struct header
{
char arch_name[NAMSIZ];
char mode[8];
char uid[8];
char gid[8];
char size[12];
char mtime[12];
char chksum[8];
char linkflag;
char arch_linkname[NAMSIZ];
char magic[8];
char uname[TUNMLEN];
char gname[TGNMLEN];
char devmajor[8];
char devminor[8];
/* Следующие поля были добавлены в GNU и не являются стандартными. */
char atime[12];
char ctime[12];
char offset[12];
- 178 -
char longnames[4];
/* Некоторые компиляторы сами вставляют содержимое. Но проще всегда
его вставлять! */
char pad;


struct sparse sp[SPARSE_INHDR];
char isextended;
char realsize[12]; /* истинный размер разреженного файла */
#if 0
char ending_blanks[12]; /* число нулей в конце файла, если
любое */
#endif
}
header;
struct extended-header
{
struct sparse sp[21];
char isextended;
}
ext_hdr;
};
/* Поле контрольной суммы заполняется, когда сосчитана контрольная
сумма. */
#define CHKBLANKS " " /* 8 пропусков, не нулей */
/* Поле magic заполняется этим значением, если допустимы uname и
gname, отмечающие архив, как в стандарте POSIX (сам GNU не согласован
с POSIX). */
#define TMAGIC "ustar " /* 7 символов и ноль */
/* Поле magic заполняется этим, если это элемент дампа формата GNU.
Но я полагаю, что это теперь неверно. */
#define GNUMAGIC "GNUtar " /* 7 символов и ноль */
/* Указательный флаг определяет тип файла. */
#define LF_OLDNORMAL '\0' /* нормальный дисковый файл, Unix-
- 179 -
совместимый */
#define LF_NORMAL '0' /* нормальный дисковый файл */
#define LF_LINK '1' /* указатель на предыдущий
дампированный файл */
#define LF_SYNLINK '2' /* символьный указатель */
#define LF_CHR '3' /* символьный специальный файл */
#define LF_BLK '4' /* блочный специальный файл */
#define LF_DIR '5' /* каталог */
#define LF_FIFO '6' /* специальный файл FIFO */
#define LF_CONFIG '7' /* непрерывный файл */
/* Дальнейшие типы указателей определены позже */
/* Заметьте, что стандарты допускают только прописные буквы от А до Z
для расширения, определяющего пользователя. Это значит, что определять
что-нибудь с помощью, например, '8' - плохая идея. */
/* Это элемент каталога, содержащий имена файлов, которые были в
каталоге в то время, когда был сделан дамп. */
#define LF_DUMPDIR 'D'
/* Идентифицирует NEXT файл на ленте, как имеющий длинное имя
указателя. */
#define LF_LONGLINK 'K'
/* Идентифицирует NEXT файл на ленте, как имеющий длинное имя. */
#define LF_LONGNAME 'L'
/* Это продолжение файла, который начался в другом томе. */


#define LF_MULTIVOL 'M'
/* Для хранения имен файлов, которые занимают более 100 символов. */
#define LF_NAMES 'N'
/* Это для разреженных файлов. */
#define LF_SPARSE 'S'
/* Этот файл - заголовок ленты/тома. Игнорирует его при извлечении. */
#define LF_VOLHDR 'V'
- 180 -
#if 0
/* Следующие два блока #define'ов не используются в GNU tar. */
/* В поле режима используются двоичные разряды - значения в
восьмиричных числах. */
#define TSUID 04000 /* задайте UID при выполнении */
#define TSGID 12000 /* задайте GID при выполнении */
#define TSVTX 01000 /* сохраните текст (бит). */
/* Возможности файлов */
#define TUREAD 00400 /* читать создателю */
#define TUWRITE 00200 /* записывать создателю */
#define TUEXEC 00100 /* выполнять/искать создателю */
#define TGREAD 00040 /* читать группе */
#define TGWRITE 00020 /* записывать группе */
#define TGEXEC 00010 /* выполнять/искать группе */
#define TOREAD 00004 /* читать другим */
#define TOWRITE 00002 /* записывать другим */
#define TOEXEC 00001 /* выполнять/искать другим */
#endif
/* Конец описания Стандартного Формата Архива. */
Все символы в заглавных записях представлены 8-битными символами в
локальном варианте ASCII. Все поля структуры прилегают друг к другу,
т.е. не нужно заполнять промежутки. Все символы носителя архива
хранятся смежно.
Байты, представляющие содержание файлов (после заглавной записи
каждого файла) никак не транслируются и не ограничивают представленные
символы определенным символьным множеством. В формате tar текстовые
файлы не отличаются от двоичных файлов, и трансляция содержимого
файлов не производится.
name, linkname, magic, uname and gname - заканчивающиеся нулем
символьные строки. Все остальные поля в ASCII - заполняемые нулями
- 181 -
восьмиричные числа. Каждое числовое поле ширины w содержит w-2 цифр,
пробел и ноль, за исключением size и mtime, которые не содержат нуля.
Поле field - имя файла, в котором имя кaталога предшествует имени
файла, и они разделены '/'.


FIXME: Насколько большим должно быть имя, чтобы вызвать переполнение
поля?
Поле field обеспечивает 9 бит, задающих разрешения файлам, и три
бит для задания режимов Set UID, Set GID и Save Text. Значения для
этих бит определены выше. Когда требуются специальные разрешения для
создания файла с данным режимом, и у пользователя, обновляющего файлы
в архиве, нет такого разрешения, биты режима, задающие эти специальные
разрешения, игнорируются. Режимы, которые не поддерживаются
операционной системой, обновляющие файлы из архива, игнорируются.
Неподдерживаемые режимы должны быть определены при создании или
модификации архива; разрешение группы можно скопировать с других
разрешений.
Поля uid и gid - численные идентификаторы пользователя и группы
создателя файла соответственно. Если операционная система не
предполагает таких идентификаторов, эти поля должны игнорироваться.
Поле size - размер файла в байтах; указываемые файлы архивируются с
помощью поля, заданного как ноль.
FIXME: xref Modifiers
в частности, опцию '--incremental'.
Поле mtime - модификационное время файла во время, когда он был
заархивирован. Это представление ASCII восьмиричного значения
последнего времени, когда он был модифицирован, представляемое в целом
числе секунд с 1 января 1970г. 00:00 Координационного Универсального
Времени.
Поле chksum - представление ASCII восьмиричного числа простой суммы
- 182 -
всех байт заглавной записи. Каждый 8-битный байт в заглавии
прибавляется к числу без знака, инициализированному на ноль, точность
которого должна быть не меньше семнадцати бит. При вычислении
контрольной суммы поле chksum рассматривается, как состоящее из одних
пропусков.
Поле typeflag задает тип заархивированного файла. Если реализация не
рассматривает или разрешает указанный тип, файл извлекается, как если
бы он был регулярным файлом. Если же он рассматривается и не
разрешается, tar выдает предостережение на стандартный вывод.
Поля atime и ctime используются в проведении пошаговых резервных


копирований, они сохраняют соответственно время доступа файлов и
последнее измененное время.
offset используется для опции '--multi-volume' ('-M') при создании
многотомного архива. offset - число байтов файла, которые нам нужны
для того, чтобы продолжить файл на следующую ленту.
Следующие поля были добавлены для работы с разреженными файлами.
Файл разрежен, если он содержит блоки, концы которых представлены
нулями, т.е. неиспользуемыми данными. Проверить, разрежен ли файл -
значит, посмотреть число блоков, занимаемых файлом и сравнить его с
числом символов файла: если блоков, выделяемых под файл, меньше, чем
должно выделяться под файл такого размера, то файл разреженный. Этот
метод tar использует для определения разреженного файла, и если такой
файл найден, он рассматривается отдельно от неразреженных файлов.
Разреженные файлы - часто файлы dbm или других типов базы данных,
которые имеют данные на некоторых местах и пустоту в большей части
файла. Такие файлы возникают, когда к ним применяется 'ls -l', они
могут содержать очень мало важных данных. Таким образом нежелательно,
чтобы tar производил резервное копирование этих файлов, когда много
места занято пустыми блоками, что может привести к истощению места на
диске гораздо раньше, чем надо бы. Т.ч. нужно рассматривать вопрос
таким образом, чтобы пустые блоки не записывались на ленту. Вместо
этого на ленту записывается описание разреженного файла: сколько дыр,
насколько они велики, сколько данных находится в конце дыры. Таким
- 183 -
образом файлы потенциально занимают намного меньше места на ленте, и
когда они впоследствии извлекаются, это происходит таким же образом,
как описано выше. Следующее - описание полей, используемых для работы
с разреженными файлами:
sp - массив struct sparse. Каждый struct sparse содержит две
12-символьных строки, которые представлены смещением в файл и числом
байтов, подлежащих записи в это смещение. Смещение абсолютное и не
относится к смещению предыдущего элемента массива.


Заглавие может содержать четыре struct sparse одновременно; если
нужно больше, они не сохраняются в заглавии.
Флаг isextended задается, когда нужно иметь дело с файлом. Это
значит, что этот флаг может быть установлен только при работе с
разреженным файлом, и установлен только если описание файла не
помещается на место, предназначенное для разреженных структур в
заглавии. Другими словами, нужен extended_header.
Структура extended_header используется для разреженных файлов,
которым нужно больше разреженных структур, чем может поместиться в
заглавии. Заглавие может содержать четыре таких структуры; если нужно
больше, устанавливается флаг isextended и следующая запись -
extended_header.
Каждая структура extended_header содержит массив из 21 разреженной
структуры при наличии флага isextended у заглавия. Для описания
разреженного файла может потребоваться неопределенное число таких
extended_header.
LF_NORMAL
LF_OLDNORMAL
Эти флаги представляют регулярный файл. Для совместимости со
старыми версиями tar значение typeflag LF_OLDNORMAL должно
рассматриваться как регулярный файл. Новые архивы должны
создаваться при помощи IF_NORMAL. Также, для обратной
согласованности, tar рассматривает регулярные файлы, чьи
имена заканчиваются на '/', как каталоги.
- 184 -
LF_LINK
Этот флаг представляет файл, указывающий на другой файл
любого типа, заархивированный перед ним. Такие файлы
идентифицируются в Unix с помощью файлов, имеющих то же
устройство и номер. Указываемое имя задано на поле linkname
с последним нулем.
IF_SYMLINK
Это представляет символьный указатель на другой файл.
Указываемое имя задано на поле linkname с последним нулем.
LF_CHR
LF_BLK
Представляют символьные специальные файлы и блочные
специальные файлы соответственно. В этом случае поля
devmajor и devminor содержат номера большего и меньшего
устройств. Операционная система отображает описания
устройства в собственное локальное описание или может
игнорировать элемент.
LF_DIR
Этот флаг задает каталог или подкаталог.


Имя каталога на
поле name должно заканчиваться '/'. В системах, где
заполнение диска выполняется на основе каталога, поле size
содержит максимальное число байт (которые можно привести к
ближайшей единице дискового блока), которое может содержать
каталог. Нулевое поле size не указывает такого ограничения.
Системы, не предполагающие такого ограничения, игнорируют
поле size.
LF_FIFO
Задает специальный файл FIFO. Заметьте, что архивируется
только существование файла FIFO, а не содержимое.
LF_CONFIG
Задает непрерывный файл, который отличается от обыкновенного
тем, что в операционной системе, которая его поддерживает,
- 185 -
нет пропусков. Операционные системы, не позволяющие
непрерывного размещения, рассматривают этот файл как
обыкновенный.
A...Z
Зарезервированы для реализаций клиентов. Некоторые из них
используются в модификационном формате GNU (см.ниже).
Другие значения зарезервированы для задания при будущих проверках
стандарта P1003 и не должны использоваться программой tar.
Поле magic показывает, что этот архив был выведен в форматe P1003.
Если это поле содержит TMAGIC, поля uname и gname будут содержать
представление ASCII создателя и группы файла соответственно.
Идентификаторы пользователя и группы используются скорее, чем поля uid
и gid.
11.2 Дополнения GNU к формату архива *
Формат GNU использует дополнительные типы файлов для описания новых
типов файлов архива. Они перечислены ниже.
LF_DUMPDIR
'D'
Представляет каталог и список файлов, созданный опцией
'--incremental'. Поле size дает общий размер
ассоциированного списка файлов. Каждому имени файла
предшествует или 'Y' (этот файл должен быть в архиве) или
'N' (файл - каталог, или не хранится в архиве). Каждое имя
файла заканчивается нулем. Существует дополнительный ноль
после последнего имени файла.
LF_MULTIVOL
'M'
Представляет файл, продолжающийся из другого тома
многотомного архива, созданного с помощью опции
'--multi-volume'. Начальный тип файла здесь не дается. Поле


- 186 -
size дает максимальный размер этого куска файла
(предполагается, что том не кончается до тех пор, пока файл
не записан). Поле offset дает смещение от начала файла до
того места, где начинается эта часть файла. Таким образом,
size + offset - то же самое, что начальный размер файла.
LF_SPARSE
'S'
Этот флаг показывает, что мы имеем дело с разреженным
файлом. Нужно отметить, что архивирование разреженного файла
требует специальных операций для нахождения дырок в файле,
отмечающих положения этих дырок и выявляющих число
байт данных, найденных после дырки.
LF_VOLHDR
'V'
Этот тип файла используется для того, чтобы отмечать
заглавие тома, которое было дано с помощью опции
'--label=архивная_метка'. Поле size - нулевое. Только первый
файл каждого тома архива должен иметь этот тип.
У вас могут появиться сложности при чтении архива формата GNU в
не-GNU системах, если при этом были использованы опции '--incremental'
('-G'), '--multi-volume' ('-M'), '--sparse' ('-S') или
'--label=архивная_метка'. Обычно, если tar не использует поля,
добавленные GNU, в заглавии, другие версии tar могут читать архив. В
противном случае программа tar выдает ошибку, в лучшем случае это
ошибка контрольной суммы.
11.3 Сравнение tar и cpio *
Здесь приведен перечень различий между tar и cpio. Точность этой
информации еще не проверялась. Написанию этого раздела, в основном
через обзор 1991 года, способствовали следующие люди:
Бент Бертельсен dmdata@login.dkuug.dk
Давид Хупес talgras!david
- 187 -
Гей Харрис guy@auspex.com
Кай Петцке wpp@marie.physic.tu-berlin.de
Кристен Нильсен dmdata@login.dkuug.dk
Лесли Майкшелл les@chinet.chi.il.us
FIXME: Реорганизовать следующий материал
tar работает с символьными указателями в той форме, что в BSD; cpio
же не имеет дела с символьными указателями в форме System V,
предшествовавшей SVR4, и некоторые продавцы добавляли в свои системы
символьные указатели, в то же время не давая cpio о них никакой
информации. Другие делают это, но не тем способом, каким я это делал в


Sun и который был принят AT&T (и который, я думаю, присутствует в том,
что Беркли взял из AT&T и вложил в поздний BSD - мне кажется, туда
попали мои изменения).
(SYR4 не так хорош с tar; в основном его cpio может работать с
вводом формата tar и записывать его на вывод, и , вероятно, работает с
символьными указателями. Они могут ничего не пытаться сделать для
того, чтобы усилить tar.)
cpio работает со специальными файлами, а традиционный tar - нет.
tar произошел из V7, System III, System V и BSD; cpio - из System
III, System V и позднего BSD (4.3 и позже)
Способ tar обработки множественных указателей на файл может
обрабатывать системы файлов, предполагающие 32-битные номера (так же,
как система файлов BSD); метод сpio требует от вас игры в некоторые
игры (в его "двоичный" формат, i-числа и только 16 бит, и его
"мобильный формат ASCII", 18 бит; он должен играть в игры с
полем "идентификатора системы файлов" заглавия для того, чтобы
убедиться, что идентификатор системы файлов / i-число - пара разных
файлов - всегда разные).
При способе tar обработки множественных указателей на файл на ленту
помещается только одна копия указателя, но имя, относящееся к этой
копии - единственное, которое вы можете использовать для извлечения
- 188 -
этого файла; cpios тоже кладет только одну копию каждого указателя, но
вы можете извлечь его, используя любое из имен.
>Какой тип контрольной суммы используется, и как ее сосчитать.
О формате tar и cpio см. руководства. tar использует контрольную
сумму, которая является суммой всех байт заглавия файла; cpio не
использует контрольных сумм.
>Знает ли кто-нибудь, зачем нужно было делать cpio, когда уже был
tar? Сообщите мне, пожалуйста.
cpio впервые появился в PWB/UNIX 1.0; UNIX тогда не имел ни одной
общедоступной версии tar. Я не знаю, была ли в AT&T какая-нибудь
версия tar или, может быть, люди в AT&T, создавшие cpio, вообще не
знали о нем.
Если при обновлении на ленте есть повреждения, tar останавливается в


этом месте, а cpio его перескакивает и пытается обновить остаток
файлов.
Основное различие - в синтаксисе команд и формате заглавия.
tar более ориентирован на ленты, и во всем, что разбито на блоки,
начинает работу с границы блока.
> Есть ли какие-нибудь различия в способности обновлять поврежденные
архивы (если их вообще можно восстановить)?
Теоретически это должно быть легче под tar, т.к. разбиение на блоки
позволяет находить заглавие с помощью некоторых вариаций 'dd skip=nn'.
Однако в современном cpio и вариациях есть опция поиска заглавия
следующего файла после ошибки с возможностью ресинхронизации. Но
программное обеспечение драйверов многих лент не позволяет продолжать
работу после ошибки носителя, что является единственной причиной
использования синхронизации, если файлы не меняли размеров, когда вы
записывали архив.
- 189 -
>Знает ли кто-нибудь, зачем нужно было делать cpio, когда уже был
tar? Сообщите мне, пожалуйста.
Наверно, потому, что он более эффективен с точки зрения носителей
(не разбивая все на блоки и используя только место, необходимое для
заглавия, в то время как tar всегда использует для каждого файла
минимум 512 байт) и может архивировать специальные файлы.
Может, вы захотите ознакомиться с доступными альтернативами. Это
afio, GNU tar и pax, каждый из которых имеет свои расширения с
определенной обратной связью.
Разреженные файлы были определены как разреженные с помощью tar (и
их можно легко выявить, а GNU cpio их вообще не читает).