日本語 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
交換フォーマット'' を定義しています。なお、pax 交換フォーマットアーカイブ
は、あらゆる点で ustar アーカイブです。新しいデータは ustar 互換のアーカ
イブエントリに、typeflag に ``x'' および ``g'' を使用して記録されます。特
に、これらの拡張機能を完全にサポートしない古い実装では、このメタデータを
必要に応じて検査できるよう、通常ファイルとして展開するでしょう。
pax 交換フォーマットアーカイブのエントリは、1 つか 2 つの標準 ustar エン
トリを含み、それぞれヘッダとデータを持ちます。最初のオプションエントリ
は、これに続くエントリに対する拡張属性を記録しています。この最初のオプ
ションエントリは typeflag "x" を持ち、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 で符号化されるので、非アスキー文字を含める
ことができます。UID および GID フィールドは、任意の長さに出来ま
す。
linkpath
ファイルにリンクするフルパス。なお、これは UTF8 で符号化されるの
で、非アスキー文字を含めることが出来ます。
path エントリのフルパス名。なお、これは UTF8 で符号化されるので、非ア
スキー文字を含めることが出来ます。
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 で符号化されます。対応する作成プログラムは、標準 ustar ヘッダに
は可搬性のある 7 ビットアスキー文字のみを記録するべきで、テキスト値に非ア
スキー文字が含まれる場合のみに、拡張属性を使用するべきです。
これまでに述べた x エントリに加えて、pax 交換フォーマットはまた g エント
リもサポートしています。g エントリは同様の形式ですが、これに続く全ての
アーカイブエントリに与えるデフォルトの属性を指定するものです。この g エン
トリはあまり広範には用いられていません。
新しい x と g エントリの他にも、pax 交換フォーマットは初期の ustar フォー
マットに対して、他の細かい変化がいくつかあります。最も厄介なことの一つ
は、ハードリンクがこれに続くデータを持つことを許可されていることです。こ
れは読み込みプログラムに、最初のエントリを探すためにアーカイブを巻戻すこ
となく、あるファイルに対するハードリンクを展開するのを可能にします。しか
し、堅牢な読み込みプログラムに対し、ハードリンクエントリの size フィール
ドを無視するべきかどうかはっきりとしないという混乱を生じます。
GNU Tar アーカイブ
GNU tar プログラムは初期に記述された POSIX 以前のフォーマットに似たものか
ら始まり、いくつかの異なる機構で拡張されています。ヘッダの未使用空間に新
しいフィールドを追加 (それらのいくつかは、後に POSIX にて矛盾する目的で使
用されています)。ヘッダが複数のレコードに跨ることを認めている。そして続く
エントリを修飾する新しいエントリを追加 (大体において前述の x エントリに似
ていますが、多目的な x エントリとは違い、GNU の各特別エントリは単一目的で
す)、といったものです。結果として、GNU tar アーカイブは、かなり寛大な
POSIX 対応の読み込みプログラムならば、大抵の GNU tar アーカイブをうまく展
開することができるとはいえ、POSIX とは互換性がありません。
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 は、ある無名の RTOS で、ディスク上に連続したファ
イルをあらかじめ割り当てるために使用するのを除いて、タイ
プ "7" をタイプ "0" とまったく同等に扱います。
D ディレクトリエントリを意味します。POSIX 標準の typeflag
"5" とは異なり、このヘッダにはディレクトリ内にあるファイ
ルの名前の一覧データが続きます。もしファイルがこのアーカ
イブに保存されれば、ファイル名の先頭にアスキー文字の "Y"
が追加されますし、保存されなければ、"N" が追加されます。
名前はそれぞれヌルで終端され、名前の一覧の終端には追加の
ヌルがマークされます。このエントリの目的は、インクリメン
タルバックアップをサポートすることにあります。プログラム
がこのようなアーカイブを展開する場合、アーカイブが作成さ
れた時にディレクトリ内に存在しなかったファイルを、ディス
クから削除しようとするでしょう。
なお、理解できない typeflag が通常ファイルとして展開され
ることを要求している POSIX に、この typeflag "D" は明確に
違反しています。この場合、通常ファイルとして "D" エントリ
が展開されると、そのあとに同名のディレクトリを作成するの
を妨げる可能性があります。
K このエントリに対するデータは、続く通常エントリに対する長
い linkname です。
L このエントリに対するデータは、続く通常エントリに対する長
いパス名です。
M 前のボリュームの最後のファイルの続きです。GNU マルチボ
リュームアーカイブは、各ボリュームが正しいエントリヘッダ
で始まることを保証しています。これを確実にするため、ファ
イルの分割は、あるボリュームの最後と、これに続くボリュー
ムの最初に保存されると言う形でなされます。この typeflag
"M" は、このエントリが既存のファイルの続きであることを示
しています。このエントリは、アーカイブの最初か二番目のエ
ントリにのみ表れます (後者は最初のエントリがボリュームラ
ベルである場合のみ)。size フィールドは、このエントリのサ
イズを表しています。369-380 バイト目にある offset フィー
ルドは、このファイルの断片が始まるオフセットを表していま
す。realsize フィールドは、このファイルの合計サイズを表し
ています (これは size と offset を足したものと同じでなけ
ればいけません)。展開の時、GNU tar はヘッダのファイル名が
予測したものかどうかチェックし、ヘッダの offset が正しく
続いているかチェックし、そして offset と size の合計が
realsize と等しいかチェックします。
N タイプ "N" レコードを GNU tar が生成することはもうありま
せん。これは展開をした後に、リネーム又はシンボリックリン
クを張るファイルの一覧を含んでいます。これは元々は長い名
前をサポートするのに使用されました。このレコードの内容
は、行われるべき操作をテキストで記述したもので、形式は
``Rename %s to %s\n'' または ``Symlink %s to %s\n'' と
なっています。どちらの場合も、両方のファイル名は K&R C 形
式でエスケープされます。セキュリティ上の問題のために、"N"
レコードは、現在、アーカイブを読み込むとき、一般的に無視
されます。
S ``sparse'' 通常ファイルです。疎なファイルは断片の集合とし
て保存されます。ヘッダは断片の offset/length ペアの一覧を
含んでいます。もしそのようなエントリが 4 つ以上必要なら、
必要に応じて ``extra'' ヘッダ拡張 (既に使われていない古い
フォーマットです)、もしくは ``sparse'' 拡張を用いてヘッダ
を拡張します。
V この name フィールドは、テープまたはボリュームのヘッダ名
称と解釈するべきです。このエントリは一般的に、展開の際に
は無視されるべきです。
magic この magic フィールドは、``ustar'' の 5 文字と空白が続く形で保持
されています。なお、POSIX ustar アーカイブでは、ヌルが続いていま
す。
version
この version フィールドは、空白文字とヌルが続く形で保持されていま
す。なお、POSIX ustar アーカイブでは、アスキー数字の ``0'' を 2
つ使用しています。
atime, ctime
最後にファイルがアクセスされた時刻と、最後にファイル情報が変更さ
れた時刻です。mtime のように、8 進数で記録されます。
longnames
このフィールドは、どうやら既に使用されていないようです。
Sparse offset / numbytes
この構造体は、疎なファイルの断片のひとつを指定します。2 つの
フィールドは、8 進数の値を記録します。アーカイブ内で断片はそれぞ
れ、512 バイトの倍数にパディングされます。展開において、断片の一
覧がヘッダ (拡張ヘッダも含む) から集められ、読み込んだデータを適
切なオフセットで書き込みます。
isextended
もしこれが非 0 にセットされた場合、ヘッダが追加の ``sparse
header'' レコードに続きます。それぞれのレコードは以下に示す追加の
sparse ブロック 21 個などを含んでいます:
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 を記録するのに使用され
ます。このエントリの本体には、バイト 0 が続く 7 桁の 8 進数に、テ
キスト形式の 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 11.2 December 27, 2016 FreeBSD 11.2