Provided by: manpages-ja_0.5.0.0.20210215+dfsg-1_all bug

名前

       locatedb - 前置圧縮されたファイル名データベース

説明

       このマニュアルページは GNU 版 locate で用いるファイル名データベースのフォーマットについて記述したものであ
       る。  ファイル名データベースには、最後に更新された時点において、 特定のディレクトリツリー下に存在していた
       ファイルのリストが含まれている。

       複数のデータベースを共存させることもできる。 環境変数やコマンドラインオプションを指定すれば、  ユーザーは
       locate  に検索させるデータベースを選択することができる。  詳しくは  locate(1) を見よ。 システム管理者はデ
       フォルトで用いられるデータベースの名前や、 データベースの更新頻度、  またデータベースに入れるディレクトリ
       などを選択することができる。 通常ファイル名データベースの更新は updatedb プログラムを定期的に実行させるこ
       とによって行なう (夜間が良いだろう)。詳細は updatedb(1) を見よ。

       updatedbfrcode というプログラムを呼び出して ファイル名のリストを前置圧縮 (front compression) する。
       これによってデータベースのサイズは 1/4 から 1/5 になる。 前置圧縮 (インクリメンタルエンコーディングとも呼
       ばれる) は以下のような動作をする。

       データベースのエントリはソートされたリストからなっている  (ユーザーの利便性のため、大文字小文字は区別して
       いない)。 従って、各々のエントリは直前のエントリと最初の数文字が一致していることが多い。 それぞれのデータ
       ベースエントリには、 まずオフセット差分カウントという 1 バイトのデータが入っている。 これは現在のエントリ
       と直前のエントリの共有部分の文字数から、 直前のエントリとそのもうひとつ前のエントリの共有文字数を引いたも
       のである (従ってこの数値は負になることもある)。 カウントの後には共有部分の文字列以降の残りが ASCII 文字列
       で与えられる。 これはヌル文字で終端するとみなされる。

       もしオフセット差分カウントがバイトデータで与えられる範囲  (+/-127) を越えた場合は、バイトデータ 0x80 がカ
       ウントに代入され、 2 バイトのワードデータがその後に続く。 このワードデータでは高位バイトが先に来る  (ネッ
       トワークバイトオーダー)。

       すべてのデータベースは、 ファイルエントリの最初に `LOCATE02' というダミーのエントリを持つ。 これは locate
       によってチェックされ、  このデータベースが正しいフォーマットであることを確認するために用いられる。 実際の
       検索においてはこのエントリは無視される。

       複数のデータベースを連結することはできない。 最初の (ダミー) エントリを結合するデータベースから取り去れば
       良さそうだが、 これは正しくない。 なぜなら後に続くデータベースの最初のエントリにおける オフセット差分カウ
       ントは正しい値を取り得ないからである。

       Unix 版 locate および find や、以前の GNU  版で用いられていた古いデータベースフォーマットも存在している。
       この古い形式のデータベースを作成する場合には、 updatedbbigramcode というプログラムを呼び出す。 古
       いフォーマットが上に述べた記述と異なる点を以下に示す。 それぞれのエントリがオフセット差分カウントのバイト
       データで始まり ヌル文字で終わる代わりに、 0 から 28 までのバイトデータが -14 から 14 までのオフセット差分
       カウントとして用いられ、  これがエントリ区切りを兼ねることになる。 この範囲外の長いオフセット差分カウント
       を示すデータには、 0x80 ではなく 0x1e  (30)  が使われる。  長いカウントを保有するデータにはホストのバイト
       オーダが用いられ (これはネットワークバイトオーダと等しいとは限らない)、 またホストの integer のワードサイ
       ズ (4 バイトのことが多い) が用いられる。 またここにストアされるデータは実際の値から 14 を引いた値になる。
       データベースの各エントリには終端バイトが無く、  30 以下の値を持つバイトデータが次のエントリの始まりである
       と認識される。

       さらに古いデータベース形式では、 ダミーエントリの代わりに先頭に 256 バイトのテーブルがあり、 ファイルリス
       トでもっとも頻繁に用いられている bigram が並べてある。 bigram  とは隣接した二つのバイトデータをインデック
       ス付けしたものである。   データベースに現われるバイトデータのうち、  最高位ビットがセットされているものは
       (残りの 7 ビットをインデックスとして) bigram テーブルのデータと置換される。 この bigram  とオフセット差分
       カウントを用いることで、  データベースの大きさは新しいフォーマットより 20-25% 小さくなっている。 しかし 8
       ビットクリーンでないという欠点を併せ持つ。 ファイル名に含まれるバイトデータのうち、  スペシャルコードに属
       するものは、  データベース中ではすべてクエスチョンマークで置き換えられる。 これは任意の一文字を表わすシェ
       ルのワイルドカードなので、 実際のファイル名に現われることはない。

       frcode への入力が以下のようなものとする(ヌル文字は改行に置き換えて ある):

              /usr/src
              /usr/src/cmd/aardvark.c
              /usr/src/cmd/armadillo.c
              /usr/tmp/zoo

       直前のエントリとの最長一致部分の長さは:

              0 /usr/src
              8 /cmd/aardvark.c
              14 rmadillo.c
              5 tmp/zoo

       frcode からの出力は、最後のヌル文字を改行に代え、カウントバイト を数字に代えると以下のようなものになる:

              0 LOCATE02
              0 /usr/src
              8 /cmd/aardvark.c
              6 rmadillo.c
              -9 tmp/zoo

              (6 = 14 - 8 また -9 = 5 - 14)

関連項目

       find(1), locate(1), updatedb(1), xargs(1)
       Finding Files (on-line in Info, or printed)

                                                                                                     LOCATEDB(5)