名前¶

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

説明¶

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

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

GNU LOCATE02 データベースフォーマット¶

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

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

もしオフセット差分カウントがバイトデータで与えられる範囲 (±127) を越えた場合は、バイトデータ 0x80 がカウントに代入され、2 バイトのワードデータがその後に続きます。このワードデータでは高位バイトが先に来ます (ネットワークバイトオーダー)。このカウントは負になることもあります（符号ビットは2バイトの最初の方にあります）。

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

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

将来的に locate データベース内のデータは、特定順での並び替えができなくなるかもしれません。並び替えを必要とする場合は、locate の出力に対してパイプにより sort -f を処理してください。

slocate データベースフォーマット¶

slocate プログラムが利用するデータベースフォーマットは locate が利用するものと似ていますが、全く同じではありません。データベースの最初のバイトは security level (セキュリティレベル) を指定しています。このセキュリティレベルが 0 のときは slocate が読み込みを行い、データベース内にのみある情報に基づいて、ファイル名の検索と表示を行います。一方、セキュリティレベルが 1 のとき、実行ユーザのデータベースアクセスが不能である場合、slocate はエントリ出力を省略する。データベースの 2 番目のバイトはゼロです。3 番目のバイト以降にデータベースエントリが続きます。データベースエントリの先頭に、差分カウントやダミーエントリが置かれることはありません。その代わりに最初の項目に対する差分カウントは、ゼロとして取り扱われます。

2 番目のエントリがデータベースに存在していたとすると、データは GNU LOCATE02 フォーマットと同様のものとして解釈されます。

古い locate データベースフォーマット¶

Unix 版 locate および find や、以前の GNU 版で用いられていた古いデータベースフォーマットも存在しています。この古い形式のデータベースを作成する場合には、updatedb は bigram と code というプログラムを呼び出します。古いフォーマットが上に述べた記述と異なる点を以下に示します。それぞれのエントリがオフセット差分カウントのバイトデータで始まりヌル文字で終わる代わりに、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)

バグ報告¶

GNU findutils オンラインヘルプ: <https://www.gnu.org/software/findutils/#get-help>
翻訳に関するバグ報告: <https://translationproject.org/team/>

その他の問題について GNU Savannah バグトラッカー経由での報告:

著作権¶

Copyright © 1994-2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

関連項目¶

find(1), locate(1), xargs(1), locatedb(5)

充実したドキュメントは <https://www.gnu.org/software/findutils/locatedb> を参照してください。
またローカルにおいては info locatedb により参照できます。