tar 形式

libarchive(3) ライブラリは、ほとんどの tar アーカイブを読み込むことができます。それは、POSIX 標準の“ustar”と“pax interchange”形式と古い GNU tar 形式の部分集合を書き込むことができます。

すべての tar 形式は、1 つ以上の 512 バイトレコードで各エントリを格納します。最初のレコードは、ファイル名、タイムスタンプ、およびモード情報を含むファイルメタデータに使用されます、そして、ファイルデータは、その後のレコードに格納されます。後の変形は、複数のレコードへのヘッダを拡張した適切なヘッダレコードの未定義の領域、またはその後のエントリの解釈を変更する特別なエントリを格納することによって拡張されています。

gnutar

libarchive(3) ライブラリは、ほとんどの GNU 形式 tar アーカイブを読み込むことができます。それは、現在、atime と ctime データと同様に、最近のロングファイル名とリンク名サポートを含んでいて、最も一般的な GNU 拡張をサポートします。 libarchive ライブラリは、マルチボリュームアーカイブ、と古い GNU ロングファイル名形式をサポートしません。新しい POSIX ベース形式を含む GNU スパースエントリを読み込むことができます。

libarchive(3) ライブラリは、atime と ctime のデータと同様に、ロングファイル名とリンク名 (linkname) のサポートを含む、GNU tar 形式を書き込むことができます。

pax

libarchive(3) ライブラリは、POSIX 準拠の pax 交換形式アーカイブを読み込み書き込みすることができます。 pax 交換形式アーカイブは、各正規のエントリの直前にキー/値の組として格納される追加属性がある別々のエントリを追加している、より古い ustar 形式の拡張です。これらの追加エントリの存在は、pax 交換形式と、古い ustar 形式の間の唯一の違いです。拡張属性は、無制限な長さがあり、 UTF-8 Unicode 文字列として格納されます。標準で定義されたキーワードは、すべて小文字です。ベンダは、すべての大文字のベンダ名を先行することによって、カスタムキーを定義することができます。 pax アーカイブを書き込むとき、libarchive は、Joerg Schilling の“star”アーカイバと少しの LIBARCHIVE キーによって定義された SCHILY キーの多くを使用します。 libarchive ライブラリは、SCHILY キーの大部分と GNU tar によって導入された GNU キーの大部分を読み込むことができます。理解していない任意のキーワードを静かに無視します。

pax 交換形式は、UTF-8 エンコーディングを使用して、ファイル名を Unicode に変換し、それらを格納します。 libarchive 3.0 より前に、libarchive は、システムのワイド文字ルーチンがネイティブに Unicode サポートしていると誤って仮定していました。これは、この仮定を満たさなかったシステムで ASCII でないファイル名で操作ミスを引き起こします。

制限された pax

また、libarchive ライブラリは、可能ならいつでも、拡張属性エントリを削除しようと試みる pax アーカイブを書き込むことができます。拡張属性エントリが長いファイル名、長いリンク名、拡張 ACL、ファイルフラグを格納する必要がないなら、または標準の ustar データ (ユーザ名、グループ名、UID、GID など) のいずれかが ustar ヘッダで完全に表現することができないなら、結果は、ustar アーカイブと同じになります。すべての場合において、POSIX 準拠の pax 交換形式アーカイブを読み込むことができるどんなプログラムでも結果をアーカイブから取り出す (dearchive) ことができます。 ustar 形式 (下記参照) を正しく読み込むプログラムは、この形式も読み込むこともできます。任意の拡張属性は、 PaxHeader ディレクトリに格納された個別のファイルとして抽出されます。

ustar

libarchive ライブラリは、この形式を読み込み書き込みすることができます。この形式には、次の制限があります:

• デバイスのメジャとマイナ番号は、21 ビットに制限されます。大きい数があるノードは、アーカイブに追加されません。
• アーカイブ中のパス名は、255 バイトに制限されます。 (右の位置に正確に / 文字がなければ、短くします。)
• シンボリックリンクとハードリンクは、参照されたファイルの名前でアーカイブに格納されます。この名前は、100 バイトに制限されます。
• 拡張属性、ファイルフラグ、と他の拡張セキュリティ情報は、格納することができません。
• アーカイブエントリは、8 ギガバイトのサイズに制限されます。

pax 交換形式には、これらの制限がないことに注意してください。 ustar 形式は、古くて広くサポートされています。互換性が主要な事柄であるとき、推奨されます。

また、libarchive ライブラリは、基本的な tar 形式のいろいろな一般に使用される拡張を読み込みます。これらの拡張は、それらが現れるときはいつも、自動的に認識されます。

数値拡張

POSIX 標準は、ターミネータのために予約されている、いくつかの文字位置に書き込まれている固定長の数字フィールドを必要とします。 libarchive は、ターミネータ文字なしでこれらのフィールドに書き込むことができます。これは、許容可能な範囲を拡張しています。特に、この拡張がある ustar アーカイブは、最大 64 ギガバイトのサイズまでのエントリをサポートすることができます。また、libarchive は、ほとんどの数字フィールドの base-256 値を認識します。これは、本質的にファイルサイズ、更新時刻とデバイス番号ですべての制限を取り除きます。

Solaris 拡張

libarchive は、ACL と Solaris tar によって書かれた拡張属性レコードを認識します。現在、libarchive には、古いスタイルの ACL のサポートのみがあります。新しい NFSv4 ACL は、認識されますが、破棄されます。

最初の tar プログラムは、1979 年の Seventh Edition Unix で登場しました。 tar ファイル形式のための最初の公式の規格は、1988 年に POSIX によって定義された“ustar” (unix 標準 tar) 形式でした。 POSIX.1-2001 は、“pax 交換”形式を作成するために ustar 形式を拡張しました。

cpio 形式

libarchive ライブラリは、多くの一般的な cpio 変形を読み込むことができ“odc”と“newc”形式アーカイブを書き込むことができます。 cpio アーカイブは、可変長のファイル名と可変長のデータが後に続く固定サイズヘッダとして各エントリを格納します。 tar 形式と異なって、cpio 形式は、ヘッダまたはファイルデータに最小の詰め物だけをします。どのように初期のヘッダを格納するかが主に異なるいくつかの cpio 形式があります: いくつかは、ASCII の 8 進か 16 進数として値を格納し、他は、バイト順と長さを変えるバイナリの値として格納します。

binary

libarchive ライブラリは、元のバイナリ cpio 形式のビッグエンディアンとリトルエンディアン異形の両方を透過的に読み込みます。この形式は、ファイルサイズと mtime には、32 ビットのバイナリ値を使用し、他のフィールドのためには、16 ビットのバイナリ値を使用します。

odc

libarchive ライブラリは、“cpio 交換形式”または“オクテット指向 (octet-oriented) cpio アーカイブ形式”として公式に知られ、どきどき“古い文字形式”として非公式に参照される、この POSIX 標準形式を読み込み書き込みすることができます。この形式は、ASCII で 8 進の値としてヘッダの内容を格納します。それは、標準で、移植可能で、バイト順混乱の心配がありません。ファイルサイズと mtime は、33 ビット (8GB のファイルサイズ) に制限されて、他のフィールドは、18 ビットに制限されます。

SVR4

libarchive ライブラリは、この形式の CRC と非 CRC 変形の両方を読み込むことができます。 SVR4 形式は、すべてのヘッダフィールドに 8 桁の 16 進の値を使用します。これは、ファイルサイズを 4GB に制限して、 mtime と他のフィールドを 32 ビットに制限します。 libarchive は、現在、この CRC について確かめられていませんが、 SVR4 形式は、オプションでファイルの内容の CRC を含むことができます。

cpio は、1977 年に AT&T 中でリリースされた、PWB/UNIX 1.0 ではじめて登場しました。 PWB/UNIX 1.0 は、1981 年に AT&T の外でリリースされた、 System III Unix の基礎を形成しました。これで、cpio は、tar より古くなりますが、cpio は、Version 7 AT&T Unix には含まれていませんでした。その結果、tar コマンドは、Version 7 を使用した大学と研究グループではるかによく知られるようになりました。 find と cpio ユーティリティの組み合わせは、ファイル選択を行う上でたいへん正確な制御を提供しました。残念ながら、その形式には、それを広範に使用することを不適切とする多くの制限があります。 POSIX 形式だけが 4GB 以上のファイルを可能にし、他のほとんどのフィールドのための 18 ビットの限界は、現代のシステムに不適切です。さらに、cpio の形式は、異なるユーザの番号付けで、システムの向こう側に正しくアーカイブを転送することを非常に難しくする、 (ユーザ名とグループ名でない) 数値の UID/GID 値を格納するだけです。

shar 形式

“シェルアーカイブ”は、POSIX 準拠のシステムで実行されるとき、ファイルシステムオブジェクトの収集を再現するシェルスクリプトです。 libarchive ライブラリは、2 つの異なった種類の shar アーカイブを書くことができます:

shar

伝統的な shar 形式は、 echo(1), mkdir(1) と sed(1) を含む限られたひとそろいの POSIX コマンドを使用します。それは、プレーンテキストファイルの小さな収集を移植可能状態でアーカイブするのに適当です。しかしながら、それは、一般的に大きなアーカイブに適していませんし、 ( sh(1) の多くの実装には、スクリプトのサイズに制限があります) テキストでないファイルにそれを使用するべきではありません。

shardump

この形式は、shar と同様ですが、結果がファイルの内容にかかわらずプレーンテキストファイルになるように uuencode(1) を使用してファイルをエンコードします。また、それは、所有者、モードとフラグ含んで、できるだけ多くのファイル属性を再現しようと試みる追加のシェルコマンドを含んでいます、ファイル属性を復旧するために使用される追加コマンドは、shardump アーカイブを単純な shar アーカイブよりも移植性がないようにします。

ISO9660 形式

libarchive は、ISO9660 準拠の CDROM イメージに含まれるファイルを読み込み、抽出することができます。多くの場合、これは、単に ISO9660 イメージ中に含まれたファイルを読み込むために、物理的な CDROM を焼く必要性を取り除くことができます。また、それは、仮想のマウントとループバックデバイスをもたらすセキュリティと複雑さの問題を避けます。 libarchive は、最も一般的な Rockridge 拡張をサポートし、Joliet 拡張の部分的なサポートもあります。両方の拡張が存在しているなら、Joliet 拡張が使用され、Rockridge 拡張は、無視されます。特に、これは、Joliet にはない、Rockridge によってサポートされるハードリンクとシンボリックリンクの問題を生じさせます。

libarchive は、ストリーミング戦略を使用する ISO9660 イメージを読み込みます。これによって、圧縮されたイメージを直接 (その場で圧縮復元して) 読み込むことができ、ネットワークソケット、パイプと他のシーク不可能なデータソースから直接をイメージを読み込むことができます。この戦略は、多くの一般的なプログラムによって作成された、最適化された ISO9660 イメージに対してよく動作します。そのようなプログラムは、ISO9660 イメージの最初で、すべてのディレクトリ情報を収集するので、最小のシークで物理的なディスクからそれを読み込むことができます。しかしながら、すべての ISO9660 イメージは、この方法で読み込むことはできません。

また、libarchive は、ISO9660 イメージを書き込むことができます。そのようなイメージは、すべてのファイルデータに先行するディレクトリの情報で完全に最適化されます。これは、メモリ中のディレクトリ情報を収集する間にテンポラリファイルへのファイルデータをすべて格納することにより行われます。イメージが終了するとき、libarchive は、ファイルデータが後続するディレクトリ構造を書き込みます。テンポラリファイルのために使用される位置は、通常の環境変数によって変更することができます。

zip 形式

libarchive は、圧縮復元されたエントリと“deflate”アルゴリズムで圧縮されたエントリがある zip 形式アーカイブを読み書きすることができます。それは、現在、非圧縮したエントリと“デフレート”アルゴリズムで圧縮されたエントリのみをサポートします。他の zip 圧縮アルゴリズムは、サポートされません。それは、jar アーカイブ、Zip64 拡張を使用するアーカイブ、と自己抽出する zip アーカイブを抽出することができます。 libarchive は、Zip アーカイブを読み込むために、次の 2 つの異なる戦略のいずれかを使用することができます: 速くて非常に大きなアーカイブと扱うことができるストリーミング戦略、と自己抽出の Zip アーカイブと削除されたメンバまたは他のインプレース (in-place) 修正があるアーカイブを正確に処理することができるシーク戦略です。

ストリーミングリーダ (reader) は、それらが読み込まれるように、Zip アーカイブを処理します。それは、テープまたはネットワークのソケットから任意のサイズのアーカイブを読み込むことができ、別々に圧縮されたかまたはエンコードされた Zip アーカイブをデコードすることができます。しかしながら、自己抽出の Zip アーカイブと修正の特定のタイプがあるアーカイブは、正確に扱うことができません。そのようなアーカイブは、リーダが、通常、Zip アーカイブの終わりに位置し、したがって、ストリーミングリーダ (reader) にとってアクセスできない、 Central Directory (中央のディレクトリ) を最初に処理することを必要とします。 libarchive を使用するプログラムに有効にされたシークサポートがあるなら、 libarchive は、最初に中央のディレクトリを処理するために、これを使用します。

特に、シーキングリーダ (seeking reader) は、自己抽出のアーカイブを正確に操作するために使用されなければなりません。そのようなアーカイブは、通常の Zip アーカイブが後続するプログラムから成ります。ストリーミングリーダ (reader) は、最初のプログラム部分を解析することができませんが、シーキングリーダ (seeking reader) は、アーカイブの終了から Central Directory (中央のディレクトリ) を読み込むことによって開始します。同様に、インプレース (in-place) で修正された Zip アーカイブは、最初に Central Directory (中央のディレクトリ) を読み込むことによって削除されたエントリまたは正確に検出することだけができる他のごみのデータがあるかもしれません。

アーカイブ (ライブラリ) ファイル形式

( ar(1) アーカイバによって共通に作成される) Unix アーカイブ形式は、リンクエディタ ld(1) によって読み込まれるオブジェクトファイルのためにほとんど独占的に使用される汎用形式です。 ar 形式は、一度も標準化されたことがありません。 2 つの共通的な変異型があります: SVR4 に由来する GNU 形式と 4.4BSD ではじめて登場した BSD 形式です。 2 つは、主として 15 文字より長いファイル名の取り扱いで異なります: GNU/SVR4 変異型は、アーカイブの始めにファイル名のテーブルを書き込みます。 BSD 形式は、エントリに隣接している拡張領域に各ロングファイル名を格納します。 libarchive は、両方のロングファイル名のタイプを含むアーカイブを含んで、両方の拡張を読み込みことができます。 libarchive を使用するプログラムは、エントリのいずれか前に、アーカイブに書き込まれるファイル名のテーブルを提供しているなら、 GNU/SVR4 形式を書き込むことができます。名前がファイル名のテーブルにない、すべてのエントリは、 BSD スタイルのロングファイル名を使用して書き込まれます。これは、BSD スタイルのロングファイル名をサポートしない GNU ld のようなプログラムに対して問題を起こすかもしれません。

mtree

libarchive は、 mtree(5) 形式でファイルを読み込み書き込みすることができます。この形式は、真のアーカイブ形式ではなく、むしろ各行がファイルの名前を指定し、そのファイルに関する特定のメタデータを提供するファイルの階層構造のテキスト型の記述です。 libarchive は、 mtree(8) の NetBSD と FreeBSD バージョンの両方でサポートされたすべてのキーワードを読み込むことができますが、現在、 archive_entry オブジェクトにキーワードの多くを格納することができません。書き込むとき、libarchive は、どのキーワードが出力に含まれるべきであるかを指定する archive_write_set_options(3) インタフェースの使用をサポートしています。 libarchive が (OpenSSL ライブラリのような) 適切な暗号のライブラリへのアクセスでコンパイルされたなら、書き込まれているファイルデータから mtree ライタ (writer) まで sha512 または md5 のようなハッシュエントリを計算できます。

mtree ファイルを読み込むとき、libarchive は、存在しているか、または通常のファイル名なら、 contents キーワードを使用してディスク上の対応するファイルを位置付けます。ディスク上のファイルを位置付けて、オープンすることができるなら、 mtree ファイルから失われた任意のメタデータに書き込むために使用し、ファイルの内容を読み込んで、それらを libarchive を使用してプログラムに返します。ディスク上のファイルを位置付けて、オープンすることができないなら、 libarchive は、エントリ本体を読み込む試みのためにエラーを返します。

LHA

XXX libarchive の LHA サポートに関する情報 XXX

CAB

XXX libarchive の CAB サポートに関する情報 XXX

XAR

XXX libarchive の XAR サポートに関する情報 XXX

RAR

libarchive には、RAR 形式のアーカイブを読み込むための制限されたサポートがあります。現在、libarchive は、圧縮されずに作成された、または RARv3 形式によってサポートされた圧縮方法のいずれかを使用して圧縮された RARv3 形式のアーカイブを読み込むことができます。また、libarchive は、自己抽出の RAR アーカイブを読み込むことができます。