日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
TAR(5) FreeBSD ファイルフォーマットマニュアル TAR(5)
名称
tar -- テープアーカイブファイルの形式
解説
tar アーカイブ形式は、あらゆるファイル、ディレクトリと他のファイルシステ
ムオブジェクト (シンボリックリンク、デバイスノードなど) をバイトの単一の
ストリームに収集します。形式は、元来、固定サイズのブロックで動作するテー
プドライブで使用されるように設計されましたが、一般的なパッケージ化のメカ
ニズムとして広く使用されています。
一般的な形式
tar アーカイブは、ひと続きの 512 バイトレコードから成ます。各ファイルシス
テムオブジェクトは、基本的なメタデータ (パス名、所有者、パーミッションな
ど) を格納しているヘッダレコードとあらゆるファイルデータを含んでいる 0 個
以上のレコードを必要とします。アーカイブの終わりは、すべて 0 バイトから成
る 2 つのレコードによって示されます。
固定されたブロックサイズを使用するテープドライブとの互換性のために、tar
ファイルを読み込むか、または書き込むプログラムは、各 I/O 操作で、常に固定
されたレコード数を読み込むか、または書き込みます。これらの ``blocks'' (ブ
ロック) は、常にレコードサイズの倍数です。初期の実装によってサポートされ
た最大のブロックサイズは、10240 バイトまたは 20 レコードでした。これは、
ほとんどの実装に対してデフォルトですが、1 MiB (2048 レコード) 以上のブ
ロックサイズは、近代的な高速テープドライブで一般的に使用されています。
(注: 用語 ``block'' (ブロック) と ``record'' (レコード) は、完全に標準と
いうわけではありません。この文書は、pdtar の文書化で John Gilmore によっ
て確立された規約に従っています。)
古いスタイルのアーカイブ形式
オリジナルの tar アーカイブ形式は、様々な実装者が必要だと分かった追加の情
報を含むように、何度も、拡張されました。このセクションは、tar プログラム
の最も初期に広く使用されたバージョンであると思われる Version 7 AT&T UNIX
に含まれる tar コマンドとして実装された変異型について説明しています。
古いスタイルの tar アーカイブのためのヘッダレコードは、次のように構成され
ます:
struct header_old_tar {
char name[100];
char mode[8];
char uid[8];
char gid[8];
char size[12];
char mtime[12];
char checksum[8];
char linkflag[1];
char linkname[100];
char pad[255];
};
ヘッダレコードのすべての未使用のバイトは、ヌル文字で満たされます。
name ヌル文字で終了する文字列として格納される、パス名。初期の tar の実
装は、(それらのファイルのハードリンクを含んで) 通常のファイルを格
納するだけでした 1 つの共通の初期の規約は、アーカイブされ、復元さ
れるディレクトリのパーミッションと所有者の情報を許可して、ディレ
クトリ名を示すために、後続する "/" 文字を使用ました。
mode ASCII の 8 進数として格納された、ファイルモード。
uid, gid
ASCII の 8 進数として所有者のユーザ id とグループ id。
size ASCII の 8 進数のとしてファイルのサイズ。通常のファイルだけのため
に、これは、ヘッダに続いているデータ量を示します。特に、この
フィールドは、ハードリングを抽出するとき、初期の tar の実装によっ
て無視されました。最近のライタ (writer) は、ハードリンクのエント
リのために、常に 0 の長さを格納するべきです。
mtime ASCII の 8 進数としてファイルの更新時刻。これは、協定世界時 (UTC)
1970 年 1 月 1 日 00:00:00 で始まる UNIX の基準時点、(epoch) から
の秒数を示します。負の値は、それらが一貫性がなく処理されるよう
に、ここで回避されるべきであることに注意してください。
checksum
ASCII の 8 進数として格納されたヘッダのチェックサム。チェックサム
を計算するために、チェックサムのフィールドをすべての空白に設定
し、次に、符号なしの算術演算を使用してヘッダのすべてのバイトを合
計します。このフィールドは、ヌル文字と空白文字が続く 6 つの 8 進
数として格納されるべきです。tar の多くの初期の実装は、システムの
間でアーカイブを転送するとき、相互運用性の問題を起こすかもしれな
い、チェックサムフィールドに対して符号つき算術演算を使用していた
ことに注意してください。最近の強固なリーダ (reader) は、両方の方
法でチェックサムを計算し、いずれかの計算が一致しているなら、ヘッ
ダを受け付けます。
linkflag, linkname
ハードリングを保存し、テープを節約するために、複数のリンクがある
ファイルは、最初に遭遇したアーカイブにのみに書き込まれます。次に
遭遇すると、linkflag は、ASCII `1' に設定され、linkname フィール
ドは、このファイルが現れる最初の名前を保持します。(通常のファイル
には、linkflag フィールドにヌルの値があることに注意してくださ
い。)
初期の tar の実装は、これらのフィールドをどうのように終わらせるかについ
て、さまざまでした。Version 7 AT&T UNIX の tar コマンドは、次の規約を使用
します (これは、また、初期の BSD マニュアルページに文書化されています):
パス名は、ヌル文字で終らなければなりません。mode, uid と gid フィールド
は、空白とヌルバイトで終わらなければなりません。サイズと mtime フィールド
は、空白で終わらなければなりません。チェックサムは、ヌルと空白によって終
ります。初期の実装は、先導する空白で数値フィールドを満たしました。これ
は、IEEE Std 1003.1-1988 (``POSIX.1'') 標準が公開されるまで、共通の慣習で
あったと思われます。最もよい移植性のために、最近の実装は、先導する 0 で数
値フィールドを満たすべきです。
POSIX 以前のアーカイブ
IEEE Std 1003.1-1988 (``POSIX.1'') の初期のドラフトは、John Gilmore の
pdtar プログラムと 1980 年代後半から 1990 年代前半まで多くのシステムの実
装のための基本として役に立ちました。これらのアーカイブは、一般的に、次の
変化とともに以下に説明された POSIX ustar 形式に従っています:
• マジックの値は、空白が続く 5 文字の ``ustar'' から成ります。ver
sion フィールドは、ヌル文字が続いている空白文字を含んでいます。
• 数値フィールドは、(最終的な標準で推奨されるような先導する 0 では
なく) 一般的に先導する空白で満たされます。
• prefix フィールドは、古いスタイルのアーカイブの 100 文字にパス名
を制限して、しばしば使用されません。
POSIX ustar アーカイブ
IEEE Std 1003.1-1988 (``POSIX.1'') は、tar(1) の準拠した実装によって読み
込み、書き込みされる標準の tar ファイル形式を定義しています。この形式は、
ヘッダで使用されるマジック値にちなんで、しばしば ``ustar'' 形式と呼ばれま
す。(名前は、``Unix Standard TAR'' の頭文字です。) それは、新しいフィール
ドで歴史的な形式を拡張しています:
struct header_posix_ustar {
char name[100];
char mode[8];
char uid[8];
char gid[8];
char size[12];
char mtime[12];
char checksum[8];
char typeflag[1];
char linkname[100];
char magic[6];
char version[2];
char uname[32];
char gname[32];
char devmajor[8];
char devminor[8];
char prefix[155];
char pad[12];
};
typeflag
エントリのタイプ。POSIX は、いくつかの新しいタイプ値で初期の
linkflag フィールドを拡張しました:
``0'' 通常のファイル。NUL (ヌル文字) は、互換性の目的のために同
義語として扱われるべきです。
``1'' ハードリンク。
``2'' シンボリックリンク。
``3'' キャラクタデバイスノード。
``4'' ブロックデバイスノード。
``5'' ディレクトリ。
``6'' FIFO ノード。
``7'' 予約されています。
その他 POSIX 準拠の実装は、通常のファイルとして、あらゆる認識さ
れない typeflag 値を扱わなければなりません。特に、ライタ
(writer) は、それらが、対応している拡張をサポートしない
リーダ (reader) によって復元することができるように、すべ
てのエントリが有効なファイル名があることを保証するべきで
す。大文字 "A" から "Z" は、カスタム拡張のために予約され
ています。ソケットとホワイトアウトエントリは、アーカイブ
することができないことに注意してください。
size フィールドは、特に、タイプに依存して異なった意味があることに
注意すべきです。通常のファイルについて、もちろん、ヘッダに続いて
いるデータの量を示しています。ディレクトリについて、それは、ディ
レクトリ空間をあらかじめ割り付けるオペレーティングシステムによっ
て使用するために、ディレクトリのすべてのファイルの合計のサイズを
示すために使用されます。すべての他のタイプについて、それは、ライ
タ (writer) によって 0 に設定され、リーダ (reader) によって無視さ
れるべきです。
magic これが POSIX 標準アーカイブであることを示すためにヌルバイトが続い
ているマジック値 ``ustar'' を含んでいます。完全な準拠は、適切に設
定された uname と gname フィールドを必要とします。
version
バージョン。これは、POSIX 標準アーカイブのために ``00'' (ASCII 数
字の 0 の 2 つのコピー) であるべきです。
uname, gname
ヌル文字で終了する ASCII 文字列としてのユーザ名とグループ名。それ
らが設定され、対応している名前がシステムに存在するとき、これら
は、uid/gid 値に優先して使用されるべきです。
devmajor, devminor
キャラクタデバイスまたはブロックデバイスエントリのためのメジャー
番号とマイナ番号。
name, prefix
パス名が長過ぎて標準形式で提供される 100 バイトに収まらないなら、
prefix フィールドまで最初の部分で任意の / 文字で分割することがで
きます。prefix フィールドが空でないなら、読み込みプログラムは、フ
ルパス名を得るために prefix の値と / 文字を通常の name フィールド
の前に追加します。標準は、ディレクトリ名で後続する / 文字を必要と
しませんが、ほとんどの実装は、互換性の理由のためにまだこれを含ん
でいます。
使用していないすべてのバイトは NUL (ヌル) に設定しなければならないことに
注意してください。
フィールドの終端は、以前の実装より POSIX によって少し異なって指定されま
す。magic, uname と gname フィールドは、後続する NUL (ヌル文字) がなけれ
ばなりません。pathname, linkname と prefix フィールドは、それらが全体の
フィールドを満たさないなら、後続する NUL (ヌル文字) がなければなりませ
ん。(特に、たまたま 156 番目の文字として / があるなら、256 文字のパス名を
格納することが可能です。) POSIX は、最前部で数値フィールドを 0 で埋めるこ
とを要求し、空白か、または NUL (ヌル) 文字のいずれかで終了していることを
必要としています。
現在、ほとんどの tar の実装は、ustar 形式に準拠していて、ヘッダレコードの
終わりで新しいフィールドを空白の領域に追加することによって、時々、それを
拡張しています。
数値拡張
どのくらいの数がヘッダに格納されるかを修正することによってサポートされる
サイズまたは時間の範囲を拡張するいくつかの試みがありました。
ファイルのサイズを増加させる 1 つの明白な拡張は、様々な数値フィールドから
終了文字を除去することです。例えば、標準は、サイズフィールドが後続する
NUL 文字のために 12 番目のバイトを予約して、11 個の 8 進数を単に含むこと
ができます。12 個の 8 進数であれば、ファイルサイズを最大 64 GB まで可能と
なります。
GNU tar、star と新しい tar の実装によって利用される別の拡張は、標準の数値
フィールドにバイナリ数値を許可します。これは、最初のバイトの高位ビットを
設定することによって示されます。フィールドの残りは、符号付きの 2 の補数値
として扱われます。これは、長さと時間のフィールドのための 95 ビットの値と
uid、gid とデバイス番号のための 63 ビットの値を許可します。特に、これは、
負の時間の値を扱う一貫した方法を提供しています。GNU tar は、length、
mtime、ctime と atime フィールドに対してこの拡張をサポートしています。
Joerg Schilling の star プログラムと libarchive ライブラリは、すべての数
値フィールドに対してこの拡張をサポートしています。この拡張は、pax 交換形
式によって提供される拡張属性レコードによって大部分は時代遅れにされること
に注意してください。
別の初期の GNU 拡張は、8 進数ではなく base-64 を許可しました。この拡張
は、短命で、あらゆる実装によっても、もはやサポートされていません。
pax 交換形式
POSIX ustar アーカイブに可搬性があるように格納することができない多くの属
性があります。IEEE Std 1003.1-2001 (``POSIX.1'') は、エントリに続いている
ことに適用するテキストの書式化されたメタデータを保持するためにエントリの
2 つの新しいタイプを使用する ``pax interchange format'' (pax 交換形式) を
定義しています。pax 交換形式のアーカイブは、あらゆる点で ustar アーカイブ
であることに注意してください。新しいデータは、``x'' または ``g'' typeflag
を使用する ustar 互換性のあるアーカイブのエントリで格納されます。特に、こ
れらの拡張を完全にサポートしない古い実装は、必要に応じて、メタデータを調
査することができるところで、通常のファイルにメタデータを抽出します。
pax 交換形式のアーカイブのエントリは、それぞれそれ自体のヘッダとデータが
ある、1 つまたは 2 つの標準の ustar エントリから成ります。最初のオプショ
ンのエントリは、続くエントリのための拡張された属性を格納します。このオプ
ションの最初のエントリには、"x" typeflag と拡張された属性の合計のサイズを
示す size フィールドがあります。拡張された属性のそれら自体は、移植性のあ
る UTF-8 エンコーディングでエンコードされたひと続きのテキスト形式の行とし
て格納されます。各行は、10 進数、空白、キー文字列、等号、値文字列と改行か
ら成ります。10 進数は、初期の長さフィールドと後続する改行を含んで、全体の
行の長さを示します。そのようなフィールドの例は、次の通りです:
25 ctime=1084839148.1212\n
すべての小文字のキーは、標準のキーです。ベンダは、すべて大文字のベンダ名
とピリオドで、それらの前に付けることによって、それら自体のキーを追加する
ことができます。歴史的なヘッダとは違って、数値は、8 進数ではなく、10 進数
を使用して格納されることに注意してください。いくつかの共通のキーの説明が
続いています:
atime, ctime, mtime
ファイルのアクセス時刻、inode の変更時刻と更新時刻。これらの
フィールドは、負の値を指定することができるか、または小数点と分数
値を含むことができます。
hdrcharset
文字セットは、pax 拡張値によって使用されます。デフォルトで、pax
拡張属性のすべてのテキスト値は、パスネーム、ユーザ名とグループ名
を含む、UTF-8 であると仮定されます。ある場合に、ローカルな仕様を
UTF-8 に変換することはできません。このキーが存在し、値が 6 文字の
ASCII 文字列 ``BINARY'' であるなら、すべてのテキスト値は、プラッ
トフォーム依存のマルチバイトエンコードであると仮定されます。この
キーに対する 2 つの有効な値だけがあることに注意してください:
``BINARY'' または ``ISO-IR 10646 2000 UTF-8'' です。他の値は、標
準によって許可されず、後の値は、このキーが指定されないとき、デ
フォルトのように、一般的に使用されるべきではありません。特に、こ
のフラグは、ファイル名を任意のエンコーディングで格納できる一般的
なメカニズムとして使用されるべきではありません。
uname, uid, gname, gid
ユーザ名、グループ名と数値 UID と GID 値。ここに格納されたユーザ
名とグループ名は、UTF8 でエンコードされ、したがって、非 ASCII 文
字を含むことができます。UID と GID フィールドは、任意の長さをもつ
ことができます。
linkpath
ファイルにリンクする完全なパス。UTF8 でエンコードされ、したがっ
て、非 ASCII 文字を含むことができることに注意してください。
path エントリの完全なパス名。これは、UTF8 でエンコードされて、したがっ
て、非 ASCII 文字を含むことができることに注意してください。
realtime.*, security.*
これらのキーは、予約され、将来の標準化のために使用されるかもしれ
ません。
size ファイルのサイズ。歴史的な 8GB の制限より大きなファイルを格納する
アーカイブに適合することを許可して、このフィールドに長さの制限が
ないことに注意してください。
SCHILY.*
Joerg Schilling の star 実装によって使用されるベンダ特有の属性。
SCHILY.acl.access, SCHILY.acl.default, SCHILY.acl.ace
POSIX.1e draft によって指定された形式の拡張である形式のテキスト
形式の文字列としてアクセス、デフォルトと NFSv4 ACL を格納します。
特に、各ユーザまたはグループのアクセス指定は、数値の UID または
GID がある追加のコロンで区切られたフィールドを含むことができま
す。これによって、(NIS/YP または LDAP サービスが一時的に利用でき
ないときのように) 利用可能な完全なユーザまたはグループ情報がない
システムで ACL を復旧することができます
SCHILY.devminor, SCHILY.devmajor
デバイスノードのための完全なマイナ番号とメジャー番号。
SCHILY.fflags
ファイルフラグ。
SCHILY.realsize
ディスク上のファイルの全サイズ。XXX 説明? XXX
SCHILY.dev, SCHILY.ino, SCHILY.nlinks
デバイス番号、inode 番号とエントリのためのリンクカウント。特に、
Joerg Schilling の SCHILY.* 拡張を使用している pax 交換形式のアー
カイブは、struct stat からのデータのすべてを格納することができる
ことに注意してください。
LIBARCHIVE.*
それを使用する libarchive ライブラリとプログラムによって使用され
るベンダ特有の属性。
LIBARCHIVE.creationtime
ファイルが作成されたときの時間。(これは、ファイルのメタデータが最
後に変更されたときの時間を参照する、POSIX ``ctime'' 属性と混同さ
れるべきではありません。)
LIBARCHIVE.xattr.namespace.key
libarchive は、この形式のキーを使用して POSIX.1e スタイルの拡張属
性を格納します。key 値は、URL エンコードされます: すべての非
ASCII 文字と 2 つの特殊文字 ``='' と ``%'' は、2 つの大文字の 16
進数が続いている ``%'' としてエンコードされます。このキーの値は、
base 64 でエンコードされる拡張属性値です。XXX ここで base 64 形式
を詳説します XXX
VENDOR.*
XXX 他のベンダ特有の拡張の文書 XXX
拡張された属性に格納されるあらゆる値は、通常の tar ヘッダに対応する値を上
書きします。対応するリーダは、それらが上書きされるとき、通常のフィールド
を無視するべきであることに注意してください。これは、既存のアーカイバが、
この状況の標準のヘッダフィールドに対応しない値を格納することを知っている
ことは、重要です。これらのフィールドのいずれも長さの制限はありません。特
に、数値フィールドは、任意の大きさを指定することができます。すべてのテキ
ストフィールドは、UTF8 でエンコードされます。対応するライタは、テキスト値
が ASCII でない文字を含んでいるときはいつでも、拡張された属性を使用し、可
搬性のある 7 ビット ASCII 文字だけを標準の ustar ヘッダに格納するべきで
す。
上記に記述された x エントリに加えて、pax 交換形式は、また g エントリをサ
ポートします。g エントリは、形式として同一ですが、すべてのその後のアーカ
イブエントリのためのデフォルトとして役に立つ属性を指定します。g エントリ
は、広範囲に使用されません。
新しい x と g エントリに加えて、pax 交換形式は、初期の ustar 形式から他の
いくつかの小さな変化があります。最も厄介なものは、ハードリンクが、それら
に続いているデータがあることを許可されることです。これによって、リーダ
は、初期のエントリを見つけるためにアーカイブを巻き戻さずにファイルへのあ
らゆるハードリンクファイルを普復旧することができます。しかしながら、それ
は、それらがハードリンクのエントリのための size フィールドを無視するべき
であるかどうか、もはや明確ではないので、強固なリーダに対して厄介な問題と
なります。
GNU tar アーカイブ
GNU tar プログラムは、初期に記述されたものと同様な POSIX 以前の形式で始ま
り、いくつかの異なったメカニズムを使用してそれを拡張しました: それは、新
しいフィールドをヘッダの空の空間に追加します (矛盾する目的のために POSIX
によって後に使用されたいくつか)。それによって、複数のレコードを越えてヘッ
ダを続けることができます。そして、それは、続くエントリを修正する新しいエ
ントリを定義します (上記に説明された x エントリへの方式に似ていますが、各
GNU 特別のエントリは、汎用の x エントリと違って、単一の目的です)。結果と
して、GNU tar アーカイブは、POSIX 互換ではありませんが、より寛大な POSIX
準拠のリーダは、ほとんどの GNU tar アーカイブを成功して抽出することができ
ます。
struct header_gnu_tar {
char name[100];
char mode[8];
char uid[8];
char gid[8];
char size[12];
char mtime[12];
char checksum[8];
char typeflag[1];
char linkname[100];
char magic[6];
char version[2];
char uname[32];
char gname[32];
char devmajor[8];
char devminor[8];
char atime[12];
char ctime[12];
char offset[12];
char longnames[4];
char unused[1];
struct {
char offset[12];
char numbytes[12];
} sparse[4];
char isextended[1];
char realsize[12];
char pad[17];
};
typeflag
GNU tar は、POSIX によって定義されたものに加えて、次の特別のエン
トリタイプを使用します:
7 GNU tar は、1 つ不明瞭な RTOS で、それらが、ディスクの連
続するファイルをあらかじめ割り付けられたことを示すために
使用されるところを除いて、タイプ "7" のレコードをタイプ
"0" のレコードと同一に取り扱います。
D これは、ディレクトリエントリを示します。POSIX 標準の "5"
typeflag と違って、ヘッダは、このディレクトリのファイルの
名前をリストしているデータレコードが続きます。各名前は、
ファイルがこのアーカイブに格納されるなら、ASCII "Y"、また
はファイルがこのアーカイブに格納されないなら、ASCII "N"
が先行します。各名前は、ヌルで終了され、特別なヌルは、名
前リストの終わりをマークします。このエントリの目的は、イ
ンクリメンタル (incremental) バックアップをサポートするこ
とです。そのようなアーカイブから復元しているプログラム
は、アーカイブが行なわれたとき、ディレクトリに存在しない
ディスクのファイルを削除することを望むかもしれません。
"D" typeflag は、認識されない typeflag が通常のファイルと
して復元されることを必要とする POSIX に特に違反することに
注意してください。この場合に、ファイルとして "D" エントリ
を復元することは、名前が付けられたディレクトリのようにそ
の後の作成を妨げるかもしれません。
K このエントリのためのデータは、続く通常のエントリのための
長いリンク名です。
L このエントリのためのデータは、続く通常のエントリのための
長いパス名です。
M これは、前のボリュームの最後のファイルの続きです。GNU マ
ルチボリュームアーカイブは、各ボリュームが有効なエントリ
ヘッダから始まることを保証しています。これを保証するため
に、ファイルは、1 つのボリュームの終りに格納された部分と
次のボリュームの最初に格納された部分に分割されます。"M"
typeflag は、このエントリが既存のファイルに続くことを示し
ます。そのようなエントリは、アーカイブの最初のまたは 2 番
目のエントリとしてのみ存在することができます (最初のエン
トリが、ボリュームラベルである場合のみ後者)。size フィー
ルドは、このエントリのサイズを指定します。バイト 369-380
の offset フィールドは、このファイルのフラグメントが始ま
るオフセットを指定します。realsize フィールドは、(size プ
ラス offset と等しいくなければならない) ファイルの合計の
サイズを指定します。抽出しているとき、GNU tar は、ヘッダ
ファイル名が予期しているものであり、ヘッダのオフセット
が、正しいシークエンスであり、オフセットとサイズの合計
が、realsize と等しいことをチェックします。
N タイプ "N" のレコードは、もはや GNU tar によって生成され
ません。それらは、抽出した後に、名前を変更するか、または
シンボリックリンクされるファイルのリストを含んでいます。
これは、最初に、長い名前をサポートするために使用されまし
た。このレコードの内容は、形式 ``Rename %s to %s\n'' また
は ``Symlink %s to %s\n'' で行なわれる操作のテキスト記述
です。いずれにしても、両方のファイル名は、K&R の C 構文を
使用してエスケープされます。す。セキュリティ上の問題のた
めに、"N" レコードは、現在、アーカイブを読み込むとき、一
般的に無視されます。
S これは、``sparse'' (スパース; まばらな) 通常ファイルで
す。スパースファイルは、一連のフラグメントとして格納され
ます。ヘッダは、フラグメントのオフセット/長さのペアのリス
トを含んでいます。4 つを超えるそのようなエントリが必要で
あるなら、ヘッダは、``extra'' ヘッダ拡張 (もはや使用され
ない古い形式)、または ``sparse'' (スパース) 拡張で必要に
応じて拡張されます。
V name フィールドは、テープ/ボリュームのヘッダ名として解釈
されるべきです。このエントリは、一般的に抽出で無視される
べきです。
magic マジック (magic) フィールドは、空白が続いている 5 文字の
``ustar'' を保持します。POSIX ustar アーカイブは、後続するヌルが
あることに注意してください。
version
バージョン (version) フィールドは、ヌルが続いている空白文字を保持
しています。POSIX ustar アーカイブは、ASCII の数字 ``0'' の 2 つ
のコピーを使用することに注意してください。
atime, ctime
ファイルが最後にアクセスされた時間と mtime と同様に 8 進数で格納
される、ファイル情報の最後の変更の時間。
longnames
このフィールドは、もはや明確に使用されません。
Sparse offset / numbytes
それぞれそのような構造体は、スパースファイルの単一のフラグメント
を指定します。2 つのフィールドは、8 進数として値を格納します。フ
ラグメントは、アーカイブの 512 バイトの倍数にそれぞれパディングさ
れます。抽出で、フラグメントのリストは、ヘッダ (あらゆる拡張ヘッ
ダを含んでいる) から収集され、次に、データは、適切なオフセットで
ファイルを読み込み、書き込みます。
isextended
これが 0 以外に設定されるなら、ヘッダは、追加の ``sparse header''
(スパースヘッダ) レコードが続きます。それぞれそのようなレコード
は、次に表示されるように、およそ 21 の追加のスパース (sparse) ブ
ロックの情報を含んでいます。
struct gnu_sparse_header {
struct {
char offset[12];
char numbytes[12];
} sparse[21];
char isextended[1];
char padding[7];
};
realsize
POSIX のファイルサイズよりずっと大きい範囲がある、ファイルの完全
なサイズのバイナリの表現。特に、M タイプのファイルで、現在のエン
トリは、ファイルの部分だけです。その場合に、POSIX の size フィー
ルドは、このエントリのサイズを表しています。realsize フィールド
は、ファイルの合計サイズを表しています。
GNU tar pax アーカイブ
GNU tar 1.14 (XXX これをチェック XXX) 以降は、--posix フラグを指定すると
き、pax 交換形式アーカイブを書き込むます。この形式は、いくつかの SCHILY
タグを使用し、スパースファイル情報を格納するために新しいキーワードを導入
している、pax 交換形式に綿密に従います。``0.0'', ``0.1'' と ``1.0'' とし
て参照される、スパースファイルのサポートの 3 つの繰り返しがありました。
GNU.sparse.numblocks, GNU.sparse.offset, GNU.sparse.numbytes,
GNU.sparse.size
``0.0'' 形式は、最初にファイル中のブロックの数を示すために
GNU.sparse.numblocks 属性を、各ブロックのオフセットとサイズを示す
ために GNU.sparse.offset と GNU.sparse.numbytes の組と、ファイル
の全サイズを示すために、単一の GNU.sparse.size を使用します。これ
は、後者の値が任意の穴のサイズを含んでいないので、tar ヘッダのサ
イズと同じではありません。この形式は、標準によって公式に許可され
ていない、同じ属性名の複数の出現を受け付けるリーダ (reader) で保
存され頼られる属性の順序を要求されます。
GNU.sparse.map
``0.1'' 形式は、10 進数のコンマで区切られたリストを格納する単一属
性を使用します。それぞれの数値の組は、それぞれ 1 ブロックのデータ
のオフセットとサイズを示しています。多くの pax 実装が単に認識され
ていない属性を捨てるので、アーカイブがこの拡張を認識しないアーカ
イバによって抽出されるなら、これは、うまく動作しません。
GNU.sparse.major, GNU.sparse.minor, GNU.sparse.name, GNU.sparse.realsize
``1.0'' 形式は、エントリ本体のファイルデータの前に追加された 1 つ
以上の 512 バイトのブロックでスパースブロックマップを格納します。
pax 属性は、(GNU.sparse.major と GNU.sparse.minor フィールドを通
して) このマップの存在とファイルの全サイズを示します。
GNU.sparse.name は、ファイルの真の名前を保持しています。混乱を避
けるために、普通の tar ヘッダに格納された名前は、変更された名前で
あるので、その抽出エラーで、ユーザに明らかになります。
Solaris の tar
XXX より多くの詳細が必要とされます XXX
Solaris の tar (SunOS XXX 5.7 ?? XXX で始まる) は、次の違いがある、pax 交
換形式と基本的に同様な ``extended'' (拡張) 形式をサポートします:
• 拡張された属性は、pax 交換形式によって使用されるようなタイプが x
ではなく、X であるエントリに格納されます。このエントリの詳細な形
式は、x エントリのために上記の詳細と同じとなるように思われます。
• 追加の A ヘッダは、次の通常のエントリのために ACL を格納するため
に使用されます。このエントリの本体は、7 桁の 8 進数に 0 バイトが
続き、テキスト形式の ACL 記述が続いてるものを含んでいます。8 進値
は、ACL エントリの数と 次の ACL タイプを示す定数です: POSIX.1e
ACL に対しては、01000000、NFSv4 ACL 対しては、03000000 です。
AIX Tar
XXX より詳細が必要 XXX
AIX Tar は、コード化された ACL 情報を格納するためにタイプ A がある ustar
形式のヘッダを使用します。Solaris 形式と異なり、 AIX tar は、それが適用さ
れる通常ファイルの本体の後に、このヘッダを書き込みます。このヘッダのパス
名は、格納された ACL のタイプを示す NFS4 または AIXC のいずれかです。実際
の ACL は、プラットフォーム特有のバイナリ形式で格納されます。
Mac OS X Tar
Apple's Mac OS X で配布される tar は、tar アーカイブの 2 つに分かれたファ
イルとして、ほとんどの通常のファイルを格納しています。2 ファイルには、最
初のものに、最後のパスの要素の先頭に追加された ``._'' があることを除い
て、同じ名前があります。この特殊ファイルは、ACL、拡張属性とリソースを含む
2 番目のファイルに関する、追加のメタデータで AppleDouble でエンコードされ
た バイナリブロブ (blob) を格納します。ディスク上のオリジナルのファイルを
再作成するために、それぞれ個別のファイルを抽出することができ、個別のメタ
データファイルをアンパックし、th 通常ファイルにそれを適用するために、Mac
OS X の copyfile() 関数を使用することができます。訳注: th は、意味不明、
the の誤りかもしれない。反対に、同じ関数は、個別のファイルにファイルから
の拡張メタデータをエンコードするために ``pack'' オプションを提供していま
す。次に、個別のファイルは、内容を tar アーカイブに入れることができます。
Apple の拡張属性は、長いファイル名でひどく相互に作用することに注意してく
ださい。各ファイルが、完全な名前で格納されるので、長い名前でファイルのた
めに必要なオーバヘッドを 2 倍にして、拡張の個別のセットをファイルごとに
アーカイブに含む必要があります。
tar タイプコードの要約
次のリストは、異なる tar 実装によって生成された tar ヘッダレコードで使用
されるタイプコードの要約です。特有の実装に関するより多くの詳細を、次に見
つけることができます:
NUL 初期の tar プログラムは、通常ファイルのための 0 バイトが格納されまし
た。
0 通常ファイルのための POSIX 標準タイプコード。
1 ハードリンク記述のための POSIX 標準タイプコード。
2 シンボリックリンク記述のための POSIX 標準タイプコード。
3 キャラクタデバイスノードのための POSIX 標準タイプコード。
4 ブロックデバイスノードのための POSIX 標準タイプコード。
5 ディレクトリのための POSIX 標準タイプコード。
6 FIFO のための POSIX 標準タイプコード。
7 POSIX で予約。
7 GNU tar は、いくつかのシステムであらかじめ割り付けられたファイルを使
用しました。
A Solaris tar ACL 記述は、通常ファイルヘッダの前に格納しました。
A AIX tar ACL 記述は、ファイル本体の後に格納しました。
D GNU tar ディレクトリダンプ。
K 続くヘッダのための GNU tar 長いリンク名。
L 続くヘッダのための GNU tar の長いパス名。
M ファイルが前のボリュームからのファイルの継続を示す、GNU tar マルチボ
リュームマーカ。
N GNU tar の長いファイル名のサポート。廃止予定。
S GNU tar のスパース通常ファイル。
V GNU tar テープ/ボリュームヘッダ名。
X Solaris tar の汎用拡張ヘッダ。
g POSIX pax 交換形式のグローバル拡張。
x POSIX pax 交換形式のファイルごとの拡張。
関連項目
ar(1), pax(1), tar(1)
規格
tar ユーティリティは、もはや POSIX または Single Unix Standard の一部では
ありません。それは、Version 2 of the Single UNIX Specification
(``SUSv2'') で最後に登場しました。それは、その後の標準で、pax(1) によって
取って代わられました。ustar 形式は、現在、pax(1) ユーティリティのための仕
様の一部です。pax 交換ファイル形式は、IEEE Std 1003.1-2001 (``POSIX.1'')
で新しくされました。
歴史
tar コマンドは、1979 年 1 月にリリースされた、Seventh Edition Unix で登場
しました。それは、First Edition Unix で tap プログラムを置き換え、同様
に、Fourth Edition Unix で tp プログラムを置き換えました。John Gilmore の
pdtar パブリックドメインの実装 (およそ 1987 年) は、大きな影響を及ぼしま
した、そして GNU tar (およそ 1988 年) の基礎となりました。Joerg Shilling
の star アーカイバは、pax 交換形式の完全なサポートの機能がある、(およそ
1985 年に最初に開発された) 別のオープンソース (CDDL) アーカイバです。
この文書は、libarchive と bsdtar プロジェクトの一環として Tim Kientzle
<kientzle@FreeBSD.org> によって書かれました。
FreeBSD i38.6 December 27, 2016 FreeBSD i38.6