FreeBSD 日本語マニュアル検索 (jman/japropos/jwhatis)


日本語 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.4-RELEASE-K, 13.0-RELEASE-K から 13.3-RELEASE-K, 14.0-RELEASE-K から 14.1-RELEASE-K は、全翻訳済み)

13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。



検索コマンド: man apropos whatis
コマンド/キーワード:
日本語マニュアル RELEASE :
セクション:
Table of Contents
名称 | 解説 | 関連項目 | 規格 | 歴史 | バグ
CPIO(5)             FreeBSD ファイルフォーマットマニュアル             CPIO(5)

名称
     cpio -- cpio アーカイブファイルの形式

解説
     cpio アーカイブ形式は、いろいろなファイル、ディレクトリ、と他のファイルシ
     ステムオブジェクト (シンボリックリンク、デバイスノード、など) をバイトの
     単一のストリームにまとめます。

   一般形式
     cpio アーカイブのそれぞれのファイルシステムオブジェクトは、エントリのフル
     パス名とファイルデータが基本の数値メタデータのあとに続いているヘッダレ
     コードより成ります。ヘッダレコードは、一般的に、struct stat のフールドに
     続く一連の整数値を保存します。(詳細については、stat(2) を参照してくださ
     い。) 主として、それらがどのようにそれらの整数 (バイナリ、8 進、または 16
     進) を格納しているかにより、変異型は、異なりますヘッダは、エントリのパス
     名 (パス名の長さはヘッダに格納される) と任意のファイルデータが続きます。
     アーカイブの終わりは、パス名 ``TRAILER!!!'' がある特別なレコードによって
     示されます。

   PWB format
     XXX 何かオリジナルの PWB/UNIX 1.0 形式に関する文書はありませんか ? XXX

   古いバイナリ形式
     古いバイナリ cpio 形式は、2 バイトと 4 バイトのバイナリ値として数を格納し
     ています。各エントリは、次の形式のヘッダで始まります:

           struct header_old_cpio {
                   unsigned short   c_magic;
                   unsigned short   c_dev;
                   unsigned short   c_ino;
                   unsigned short   c_mode;
                   unsigned short   c_uid;
                   unsigned short   c_gid;
                   unsigned short   c_nlink;
                   unsigned short   c_rdev;
                   unsigned short   c_mtime[2];
                   unsigned short   c_namesize;
                   unsigned short   c_filesize[2];
           };

     ここの unsigned short フィールドは、16 ビットの整数値です。unsigned int
     フィールドは、32 ビットの整数値です。フィールドは、次の通りです:

     magic   整数値 8 進の 070707。このアーカイブがリトルエンディアンまたは
             ビッグエンディアンの整数で書き込まれているかどうか決定するため
             に、この値を使用することができます。

     dev, ino
             ディスクのデバイス番号と i ノード番号。これらは、2 つのエントリが
             同じファイルを参照する場合を決定するために cpio アーカイブを読み
             込むプログラムによって使用されます。cpio アーカイブを総合的に扱う
             プログラムは、各エントリのためにこれらを区別される値に設定するた
             めに慎重であるべきです。

     mode    モードは、通常のパーミッションとファイルのタイプの両方を指定しま
             す。それは、次のいくつかのビットフィールドから成ります:
             0170000  これは、ファイルタイプビットをマスクします。
             0140000  ソケットのためのファイルタイプ値。
             0120000  シンボリックリンクのためのファイルタイプ値。シンボリック
                      リンクに関して、リンク本体は、ファイルデータとして格納さ
                      れます。
             0100000  通常のファイルのためのファイルタイプ値。
             0060000  ブロック型特殊ファイルのためのファイルタイプ値。
             0040000  ディレクトリのためのファイルタイプ値。
             0020000  キャラクタ型特殊ファイルのためのファイルタイプ値。
             0010000  名前付きパイプまたは FIFO のためのファイルタイプ値。
             0004000  SUID (set-user-ID) ビット。
             0002000  SGID (set-group-ID) ビット。
             0001000  スティッキ (sticky) ビット。いくつかのシステムでは、これ
                      は、実行形式、そして/または、ディレクトリの振る舞いを変
                      更します。
             0000777  下位 9 ビットは、一般的な POSIX 規約に従って、world、グ
                      ループとユーザの "読み込み/書き込み/実行" パーミッション
                      を指定します。

     uid, gid
             所有者の数値ユーザ ID とグループ ID。

     nlink   このファイルへのリンク数。ディレクトリは、ここで、常に少なくとも
             2 の値があります。ハードリンクされたファイルは、アーカイブ中に
             ファイルデータのすべてのコピーを含んでいることに注意してくださ
             い。

     rdev    ブロック型特殊とキャラクタ型特殊のエントリに関して、このフィール
             ドは、関連するデバイス番号を含んでいます。他のすべてのエントリタ
             イプに関して、書き込み側によって 0 に設定され、読み込み側によって
             無視されるべきです。

     mtime   1970 年 1 月 1 日の協定世界時 0 時 0 分 0 秒のエポックから始ま
             る、秒数として示されたファイルの更新時刻。4 バイトの整数は、最初
             の最上位の 16 ビットに続いて最下位 16 ビットで格納されます。それ
             ぞれの 2 つの 16 ビット値は、ネイティブのマシンバイト順序で格納さ
             れます。

     namesize
             ヘッダに続くパス名のバイト数。このカウントは、後続するヌルバイト
             を含んでいます。

     filesize
             ファイルのサイズ。このアーカイブ形式は、4 ギガバイトのファイルサ
             イズに制限されることに注意してください。4 バイトの整数の格納方法
             の説明については、上記の mtime を参照してください。

     パス名は、固定ヘッダの直後に続きます。namesize が奇数であるなら、追加のヌ
     ルバイトがパス名の後に付け加えられます。つぎにファイルデータは、奇数の長
     さになるようにヌルバイトを埋めて、追加されます。

     ハードリンクされたファイルは、特別に処理されません。完全なファイルの内容
     は、ファイルを各コピーして含まれています。

   移植性のある ASCII 形式
     Version 2 of the Single UNIX Specification (``SUSv2'') は、すべてのプラッ
     トフォームに渡って移植性のある ASCII 変異型を標準化しました。それは、
     ``old character'' (古い文字) 形式、または、``odc'' 形式として一般的に知ら
     れています。それは、古いバイナリ形式と同じ数字フィールドを格納しますが、6
     文字または 11 文字の 8 進数値としてそれらを表します。

           struct cpio_odc_header {
                   char    c_magic[6];
                   char    c_dev[6];
                   char    c_ino[6];
                   char    c_mode[6];
                   char    c_uid[6];
                   char    c_gid[6];
                   char    c_nlink[6];
                   char    c_rdev[6];
                   char    c_mtime[11];
                   char    c_namesize[6];
                   char    c_filesize[11];
           };

     フィールドは、古いバイナリ形式と同じです。名前とファイル門対は、固定の
     ヘッダに続きます。古いバイナリ形式と異なって、パス名またはファイルの内容
     の後に、追加の詰め物がありません。アーカイブされるファイルがそれら自体全
     体に ASCII であるなら、結果のアーカイブは、名前フィールドの終りのヌルバイ
     トを除いて、全体に ASCII となります。

   新しい ASCII 形式
     "新しい" ASCII 形式は、すべての数に 8 バイトの 16 進数フィールドを使用
     し、デバイス番号をメジャーとマイナ番号のために別々のフィールドに分割しま
     す。

           struct cpio_newc_header {
                   char    c_magic[6];
                   char    c_ino[8];
                   char    c_mode[8];
                   char    c_uid[8];
                   char    c_gid[8];
                   char    c_nlink[8];
                   char    c_mtime[8];
                   char    c_filesize[8];
                   char    c_devmajor[8];
                   char    c_devminor[8];
                   char    c_rdevmajor[8];
                   char    c_rdevminor[8];
                   char    c_namesize[8];
                   char    c_check[8];
           };

     以下に指定されることを除いて、フィールドは、上記の古いバイナリ形式で指定
     されたものと一致します。

     magic   文字列 ``070701''。

     check   このフィールドは、常に書き込み側によって 0 に設定され、読み込み側
             によって無視されます。その他の詳細については、次のセクションを参
             照してください。

     固定のヘッダとパス名の合計サイズが、4 の倍数となるように、パス名にヌルバ
     イトが続きます。同様に、ファイルデータは、4 バイトの倍数とするように詰め
     物をされます。この形式は、(8 ギガバイトのファイルをサポートする、古い
     ASCII 書式と違って) 4 ギガバイトのファイルしかサポートしないことに注意し
     てください。

     この形式では、ハードリンクされたファイルは、アーカイブに現れる最後のもの
     を除いて、各エントリの filesize (ファイルサイズ) を 0 に設定することに
     よって操作されます。

   新しい CRC 形式
     CRC 形式は、マジックフィールドが ``070702'' に設定され、check フィールド
     がファイルデータのすべてのバイトの sum に設定されることを除いて、前のセク
     ションで説明された新しい ASCII 書式と同じです。この sum は、すべてのバイ
     トを符号なしの値として扱い、符号なしの演算を使用して計算されます。sum の
     最下位の 32 ビットだけが格納されます。

   HP 変異型
     cpio 実装は、XXXX を使用して HPUX で配布しましたが、デバイス番号を XXX と
     異なって格納しました。

   他の拡張と変異型
     Sun Solaris は、cpio アーカイブの特別なエントリとして、ACL と拡張属性を含
     んで、拡張ファイルデータを格納するために追加のファイルタイプを使用しま
     す。

     XXX 他に? XXX

関連項目
     cpio(1), tar(5)

規格
     cpio ユーティリティは、もはや POSIX または Single Unix Standard の一部で
     はありません。それは、最後に Version 2 of the Single UNIX Specification
     (``SUSv2'') で登場しました。それは、pax(1) によってその後の規格に取って代
     わられまし。現在、移植性のある ASCII 形式は、pax(1) ユーティリティのため
     の仕様の一部です。

歴史
     オリジナルの cpio ユーティリティは、AT&T の Unix サポートグループで働いて
     いる間に、Dick Haight によって書かれました。それは、1977 年に AT&T で内部
     的に使用された Version 6 AT&T UNIX に由来する ``Programmer's Work Bench''
     である、PWB/UNIX 1.0 の一部として登場しました。両方の古いバイナリと古い文
     字形式は、``Ancient Unix'' (古い unix) ライセンスの下で SCO によってリ
     リースされた System III によれば、1980 年まで使用されていました。文字形式
     は、IEEE Std 1003.1-1988 (``POSIX.1'') の一部として採用されました。XXX
     "newc" はいつ現れましたか?  だれがそれを考案しましたか?  HP はそれらの変
     異型でいつ明らかにされましたか?  Sun は、いつ ACL と拡張属性を導入しまし
     たか?  XXX

バグ
     ``CRC'' 形式は、周期的冗長チェック (cyclic redundancy check) ではなく、簡
     単なチェックサムを使用するので、誤称です。

     古いバイナリ形式は、ユーザ ID、グループ ID、デバイス、と i ノード番号に対
     して 16 ビットに制限されます。それは、4 ギガバイトのファイルサイズに制限
     されます。

     古い ASCII 形式は、ユーザ ID、グループ ID、デバイス、と i ノード番号に対
     して 18 ビットに制限されます。それは、8 ギガバイトのファイルサイズに制限
     されます。

     新しい ASCII 形式は、4 ギガバイトのファイルサイズに制限されます。

     cpio 形式のいずれも、異なったユーザまたはグループの番号付けのあるシステム
     の間で動かすとき、絶対に必要な、ユーザまたはグループ名を格納していませ
     ん。

     特により古い cpio 変異型を書くとき、実際のデバイス/i ノード値を利用可能な
     フィールドに適合する合成された値にマップすることが必要です。非常に大きい
     ファイルシステムで、これは、より新しい形式として考えても必要です。

FreeBSD 11.2                   December 23, 2011                  FreeBSD 11.2

Table of Contents

FreeBSD マニュアル検索