2004年7月19日

バージョン 0.6 (変更履歴)

提案者 Bryan Ford

概要

多くのアプリケーションは、Webコンテンツのキャッシュや画像・動画のサムネイル版など、他の場所に保存されたコンテンツに関するキャッシュ情報を含むディレクトリを作成・管理します。速度とストレージ効率のため、バックアップ、アーカイブ、またはその他の不必要なコピーを避けたい場合がしばしばありますが、各キャッシュディレクトリを特定して個別に除外するのは手間がかかります。本仕様では、アプリケーションが作成したキャッシュディレクトリを確実に「タグ付け」するための極めてシンプルな規約を提案します。これにより、バックアップシステムやその他のデータ管理ユーティリティが容易に識別できるようになります。データ管理ユーティリティは、ユーザーの判断に応じてこれらのタグを尊重または無視できます。

問題

多くのアプリケーションプログラムは、何らかの種類のキャッシュディレクトリを作成・管理します。 これらのディレクトリには、アプリケーションのパフォーマンスを向上させる一時的な情報が保存されますが、失われた場合は他の「一次」データソースから簡単に再生成できます。 たとえば、ほとんどのWebブラウザには、ダウンロードしたインターネットコンテンツを保存するキャッシュディレクトリがあります (Mozilla は通常、$(HOME)/.mozillaの下のどこかにCacheという名前のディレクトリを使用します)。 ユーザーのホームディレクトリをバックアップ、同期、または別のマシンに転送する際、通常はキャッシュディレクトリを一切保存・転送したくありません。理由は以下の通りです。

  • キャッシュディレクトリの内容は 一般的に長期的な保存価値がありません。 なぜなら、それは他の場所に保存されたソース素材を単にミラーリングしているに過ぎず、 しばしば縮小または不完全な形式（例: 最近ユーザーが訪問したWebページの一部、 または閲覧した画像のサムネイル版）であるためです。
  • キャッシュディレクトリはかなり大きなサイズに成長する可能性があります。 特にWebブラウザのキャッシュディレクトリは バックアップストレージ容量やネットワーク帯域幅を大幅に浪費する可能性があります。
  • キャッシュディレクトリの内容は、ユーザーが単に閲覧しているだけでも頻繁に変更される傾向があり、 これにより増分バックアップや同期ソフトウェアがディレクトリツリーに多くの頻繁な「偽の変更」を検知してしまい、 増分アルゴリズムの効率が損なわれます。
  • キャッシュディレクトリ内のファイルはしばしば非常に暗号的な名前が付けられます （例: 元のソース素材の名前や内容のハッシュに基づく）。 ユーザーのホームディレクトリを走査する操作中に何千もの意味のないファイル名がスクロールされるのは、 少なくとも迷惑であり、 経験の浅いユーザーを混乱させたり不安にさせたりする可能性があります。

キャッシュディレクトリを使用するアプリケーションは非常に多く存在します。 いくつかの進化中の標準ではそのようなディレクトリの場所を標準化しようとしていますが、 ほとんどのアプリケーションは予測不能な場所に独自のキャッシュディレクトリを作成し、 他のアプリケーションとは独立して管理しています。 したがって、キャッシュディレクトリを容易に認識できる経験豊富なユーザーであっても、 バックアップやその他のディレクトリ走査操作用の適切な--excludeオプションをすべて特定してリストアップするのは非常に面倒です。 KDEの最近のバージョンなど、一部のアプリケーションは キャッシュディレクトリを/tmpまたは/var/tmpに保持しており、 これにより少なくともキャッシュコンテンツをユーザーのホームディレクトリから完全に排除するという問題を部分的に解決しています。 しかし、アプリケーションやユーザーがこれらのキャッシュを/tmpまたは/var/tmpに置きたくない理由も十分にあります。 たとえば、これらのディレクトリが容量の限られた別のパーティションにある場合や、 システムがファイルをあまりにも頻繁に（例: 1日後、または再起動のたびに）クリアしてしまうため、 キャッシュが本来の目的を効果的に果たせない場合です。

Filesystem Hierarchy Standardでは、 このようなキャッシュ情報を保持するためのシステム全体の/var/cacheディレクトリを規定していますが、 このディレクトリは一般的に誰でも書き込み可能ではなく、 システムに同梱されたアプリケーションまたはシステム管理者によってインストールされたアプリケーションのみが使用できます。 一方、XDG Base Directory Specificationでは、 アプリケーションがユーザー環境変数で指定された場所、 またはその環境変数が存在しない場合はユーザーのホームディレクトリの標準サブディレクトリにキャッシュを作成することを推奨しています。 XDGの規約により、アプリケーションは特別な権限なしで動作できますが、 各ユーザーがログイン・プロファイルで環境変数を異なる方法で設定する可能性があるため、 システム全体のバックアップやデータ管理ユーティリティが個々のユーザーのキャッシュディレクトリを確実に特定する助けにはなりません。

提案される解決策

アプリケーションがキャッシュ情報をどこに保存すべきかについて、 現時点で完璧な合意が存在しないことを踏まえ、 少なくともそのような情報を効果的に識別できるようにするための非常にシンプルな規約を提案します。 アプリケーションがキャッシュディレクトリを配置する場所を（自ら決定するか、設定されるかに関わらず）、 そのディレクトリ内に次の名前のファイルを配置する必要があります。 

CACHEDIR.TAG

このファイルは通常のファイルでなければならず、 たとえばシンボリックリンクであってはなりません。 さらに、このファイルの最初の43オクテットは、 次のASCIIヘッダ文字列でなければなりません。 

Signature: 8a477f597d28d172789f06886806bc55

ヘッダ署名では大文字小文字が区別され、 'S'の前に空白やその他の文字を含めることはできず、 コロンの後に正確に1つのスペース文字（ASCIIコード10進数32）が必要です。 ヘッダ文字列の後にファイル内にLFまたはCR/LFが続いていなくても、 そのファイルは有効なキャッシュディレクトリタグとして認識されます。 署名内の16進値は、文字列「.IsCacheDirectory」のMD5ハッシュ値です。 この署名ヘッダは、データ管理ユーティリティが無関係なCACHEDIR.TAGという名前のファイルを 誤ってキャッシュディレクトリタグとして解釈し、 たとえば貴重なデータがバックアップされない事態を避けるために必要です。

タグファイルの残りの内容は現在未規定ですが、 UTF-8エンコーディングのプレーンテキストファイルであるべきであり、 ハッシュ文字（'#'）で始まる行はコメントとして扱われ、 ファイルを読むソフトウェアによって無視されるべきです。

上記で指定された名前を持ち、内容の先頭に必要な署名を持つファイルを、 今後キャッシュディレクトリタグと呼びます。

キャッシュディレクトリタグを直接見つけて閲覧する人のために、 アプリケーションがファイル内にこの仕様への参照コメントを含めることを推奨します。 例: 

Signature: 8a477f597d28d172789f06886806bc55
# This file is a cache directory tag created by (application name).
# For information about cache directory tags, see:
#	http://www.brynosaurus.com/cachedir/

この仕様の公式「ホーム」URLは、将来的に本提案がより正式な標準になった場合、 上記から変更される可能性がありますが、その場合は旧URLに適切な転送リンクが残されます。

アプリケーションのセマンティクス

特定のディレクトリ内にキャッシュディレクトリタグが存在することは、 そのディレクトリの全体の内容（その下のすべてのサブディレクトリを含む）が、 他の適切な場所にあるソース素材から必要に応じて再生成可能なキャッシュ情報であることを示します。 キャッシュディレクトリを作成・使用するアプリケーションは、 キャッシュ情報を表す内容を持つ最上位のディレクトリに単一のキャッシュディレクトリタグを書き込むべきです。 たとえば、Mozillaがインターネットからダウンロードしたキャッシュコンテンツを保持するために $(HOME)/.mozilla/default/dg8t1ih0.slt/Cacheという名前のディレクトリを作成する場合、 その中に次のキャッシュディレクトリタグを作成します。 $(HOME)/.mozilla/default/dg8t1ih0.slt/Cache/CACHEDIR.TAG。 キャッシュコンテンツのサブディレクトリツリー全体をタグ付けするには、 キャッシュディレクトリタグは1つだけで十分です。 アプリケーションは、キャッシュディレクトリタグが消失した場合にも再生成すべきです。 例: キャッシュディレクトリ全体の内容が削除され、ディレクトリ自体は削除されない場合。

データバックアップ、転送、または同期ソフトウェアは、 設定されていれば、ディレクトリ内のキャッシュディレクトリタグの存在を、 そのディレクトリ（およびすべてのサブディレクトリ）をバックアップまたは転送操作から自動的に除外するコマンドとして解釈できます。 この「自動除外」動作をデフォルトとするか、ユーザーが明示的に要求した場合のみ採用するかは、 そのようなアプリケーションの設計者に委ねます。 短期的にはある程度の保守主義が適切ですが、 キャッシュディレクトリをデフォルトで自動的に除外することで、長期的には効率と使いやすさが向上する可能性があります。

偶発的なデータ損失に対する最大限の堅牢性を確保するため、 キャッシュディレクトリタグの組み込みサポートを持つツールは、 CACHEDIR.TAGという名前のファイルを発見した場合、 それが通常のファイルであり、上記で指定された43バイトのヘッダを実際に含んでいることを検証してから、 そのファイルがキャッシュディレクトリタグであると結論付けることが強く推奨されます。

ユーザーフレンドリーなファイルマネージャやその他のディレクトリ階層閲覧ソフトウェアも、 ディレクトリ内のキャッシュディレクトリタグの存在に気づき、 そのディレクトリの内容が自動的に管理されており、直接「閲覧」してもあまり意味がない可能性が高いことをユーザーに通知したい場合があります。

duなどのシステム管理ソフトウェアは、 パーティション上のすべてのキャッシュディレクトリの場所、使用量の合計、および報告方法を提供し、 管理者がファイルシステム上で「ソフト」な使用領域がどれだけあるかを判断する助けになるかもしれません。 同様に、ユーティリティはシステム上のすべてのキャッシュディレクトリをクリーンアップしたり、 特定の「経過時間」を超えたキャッシュディレクトリ内のファイルを削除したりできるかもしれません。

ただし、システムソフトウェアは、純粋に自動的な方法で、 任意のキャッシュディレクトリ内の「古い」ファイルを定期的に一方的に削除するべきではありません。 異なるアプリケーションはキャッシュを異なる方法で管理する必要があります。 あるアプリケーションやシステムにとって「古い」と見なされるキャッシュデータが、 別のアプリケーションにとっては「古い」と見なされない場合があります （例: 特定のデータの再生成に長い時間がかかる場合）。 将来的には、この標準を拡張して、 アプリケーションがキャッシュディレクトリタグ内に追加のメタデータを書き込めるようにし、 システムユーティリティがアプリケーションのキャッシュをグローバルにインテリジェントに管理するために必要な追加情報を提供できるようにする可能性があります。 しかし現時点では、キャッシュディレクトリタグを導入する主な目的は、 キャッシュデータをマシン間で不必要にバックアップまたはコピーすることを簡単に避けられるようにすることです。

セキュリティ上の考慮事項

自動システムバックアップにおけるキャッシュディレクトリタグの「盲目的」な使用は、 侵入者やマルウェアがシステムに与えるダメージを潜在的に増大させる可能性があります。 ユーザーやシステム管理者は、重要なディレクトリへの悪意ある

CACHDIR.TAG

の挿入に気づきにくくなる可能性があり、 たとえばそのディレクトリの内容が定期的なバックアップから除外される原因となります。 このリスクを軽減するため、バックアップソフトウェアは少なくとも、 キャッシュディレクトリタグの存在により除外されているディレクトリをユーザーに通知するべきです。 自動増分バックアップソフトウェアは「承認済み」キャッシュディレクトリのリストを維持し、 新しいキャッシュディレクトリタグが出現した場合は、システム管理者による承認後にのみそれらを尊重するべきです。 要するに、セキュリティ侵害に直面してもバックアップの堅牢性を維持するため、 キャッシュディレクトリタグはヒントとしてのみ扱うべきであり、 何をバックアップし、何をバックアップしないかの「最終決定」として扱うべきではありません。

代替アプローチ

このセクションでは、本提案の開発中に検討されたいくつかの代替案と、 本提案を指定された通りに設計した根拠について説明します。 最も一般的な質問に対処するミニFAQ形式でフォーマットされています。

  • なぜ単にアプリケーションがキャッシュディレクトリを保持する場所を標準化しないのですか？ まず、すでに複数の矛盾する標準が存在します。 たとえば、Filesystem Hierarchy Standardは /var/cacheを規定し、 KDEは現在/var/tmpを使用し、 XDG Base Directory Specificationは ユーザー定義可能な環境変数の使用を規定し、存在しない場合はユーザーのホームディレクトリ内の$(HOME)/.cacheにフォールバックします。 いずれかの標準が最終的に「勝利」したとしても、 アプリケーションキャッシュの配置を標準化することと、ユーザーがカスタマイズできるようにすることの間には必然的な緊張関係があります。 XDG仕様はこの緊張関係を明確に認識し、考慮していますが、 その柔軟性自体が、すべてのアプリケーションがXDG標準に準拠した場合でも、 システム全体のユーティリティが各ユーザーのキャッシュディレクトリを確実に特定することを困難または不可能にしています。

なぜ既存の「no-backup」や「no-dump」拡張ファイル属性（一部のオペレーティングシステムがサポート）を使用しないのですか？ 一部のオペレーティングシステム（および通常はその中の特定のファイルシステムのみ）が これらの属性をサポートしているためです。 ポータブルでないOS機能に依存するキャッシュディレクトリのタグ付けに関する規約は、 本質的に適用範囲が限定的であり、ポータブルなアプリケーションの間で広く採用される可能性は低いでしょう。 アプリケーションは、利用可能な場合にシステム固有の拡張機能をサポートすることは自由ですが、 最大限の有用性を実現するためには、 キャッシュアプリケーションがほとんど労力なしに採用できる、 極めてシンプルでポータブルな規約が本当に必要であり、それが本提案の目的です。

なぜすべてのWebブラウザが同じキャッシュを使用すべきではないのですか？ 複数のWebブラウザやその他のWebアプリケーション（すべてが同時に実行されている可能性がある）の間で単一のインターネットコンテンツキャッシュを共有することは、非常に有用で重要な目標です。 しかし、これは依然として解決が進められている相当な技術的課題を提示します。 Webコンテンツキャッシュについてそのような共有が達成されたとしても、 多くの他のアプリケーションは、まったく異なる種類のデータを保存する他のタイプのオンディスクキャッシュを維持しています。 たとえば、長時間実行される計算の中間結果や、大規模なデータセット用のスワップスペースなどです。 それらのキャッシュがまったく異なる目的を果たし、本質的に異なる方法で管理されなければならない場合、 アプリケーションがキャッシュを共有することを期待するのは合理的ではありません。 しかし、アプリケーションが少なくとも簡単な規約（ここで提案するような）を採用することで、 キャッシュをそのようなものとして容易に識別可能にすることを期待することは、依然として有用であり、はるかに現実的です。

なぜ本提案はキャッシュディレクトリのみをサポートするのですか。 アプリケーションがキャッシュとして単一のファイルしか持っていない場合はどうなりますか？ この方法の方がタグ付けスキームがはるかにシンプルで活用しやすく、 キャッシュアプリケーションに大きな負担をかけないためです。 キャッシュディレクトリタグファイルのヘッダをチェックすることに偏執的でない場合、 既存の変更されていないほとんどのバックアップ/アーカイブアプリケーションは、 かなり些細なシェルスクリプトを通じてこのタグ付け規約をすぐに活用できます。 例: 

	find . -name CACHEDIR.TAG | sed -e 's/[/]CACHEDIR.TAG$//g' >/tmp/excludes
	tar cvf /tmp/backup.tar --exclude-from=/tmp/excludes .
ディレクトリ内の個々のファイルをタグ付けすることをサポートしようとすると、 少なくともテキストファイルを解析し、ファイル名をスキャンする必要が生じる可能性が高く、 規約が当初からはるかに複雑で潜在的に繊細なものになります。 そして、どのデータがバックアップされ、どのデータがバックアップされないかに影響する標準に関しては、 明らかに可能な限りシンプルで堅牢なものを望みます。

すべてのキャッシュデータを単一のファイルに保持する既存のキャッシュアプリケーションについては、 そのキャッシュファイルを1レベル下の独自のサブディレクトリに移動し、 その新しいサブディレクトリにキャッシュディレクトリタグを書き込むことは、 それほど困難ではないはずです。 このようなわずかなディレクトリ構造の変更は、後方互換性の問題を引き起こすべきではありません。 なぜなら、旧来の場所にあるキャッシュファイルは定義上再生成可能であり、単に削除または移動できるだけだからです。 そして、ユーザーは通常、アプリケーションのキャッシュファイルやディレクトリを直接見たり理解したりすることを期待されていないため、気にしません。

結論

適切な場所にキャッシュディレクトリタグを書き込むという上記の規約を採用することで、 キャッシュディレクトリを作成・管理するアプリケーションは、 ユーザーやシステム管理者が「ソフト」なストレージ領域を特定・管理しやすくします。 これらの領域の内容はパフォーマンスに役立ちますが、マシン間でバックアップや同期する必要はありません。 本提案は、採用コストを最小限に抑えつつ堅牢性を最大化し、 最終的に広く採用される可能性を最大化するという観点から、 意図的に最もシンプルで合理的なポータブルな解決策を採用しようとしています。 それでも本提案は将来の拡張の余地を残しており、 アプリケーションがキャッシュディレクトリタグ内にキャッシュディレクトリのセマンティクスと管理に関する追加の有用な情報を含めることができるようになります。

変更履歴

  • バージョン 0.6、2019年11月4日: Webページの統合と再構成。実質的な変更はありません。

バージョン 0.5、2004年10月27日: Gregory P. Smith氏が指摘した潜在的な脆弱性に対応して、セキュリティ上の考慮事項セクションを追加。

バージョン 0.4、2004年8月10日: キャッシュタグファイル名を 「.IsCacheDirectory」から「CACHEDIR.TAG」に変更。 古い14文字のPOSIXファイルシステムおよび8.3文字のMS-DOSファイルシステムとの互換性のため。

バージョン 0.3、2004年7月29日: アプリがタグ内にこの仕様への参照コメントを含めることを推奨。 バックアップ/アーカイブアプリがタグヘッダを検証することを推奨。 タグファイル名の長さの問題について議論。

バージョン 0.2、2004年7月23日: さまざまなフィードバックに基づいて代替アプローチセクションを充実。 サムネイル管理標準への参照を削除（サムネイルディレクトリが純粋なキャッシュセマンティクスを持たないため）。

バージョン 0.1、2004年7月19日: 初回公開リリース。

アプリケーションサポート状況

キャッシュアプリケーション アーカイブ/バックアップツール
以下のアプリケーションは、ユーザーのホームディレクトリに何らかのキャッシュを作成・維持することが知られています。

本仕様を現在サポートしているアプリケーション:

開発者から肯定的な回答を得た:

開発者との議論を開始した:

以下のアーカイブツールがこのタグ付け規約をサポートしています:

その他のアーカイブツール（まだ）キャッシュタグに直接対応していませんが、 適切なオプションやシェルマジックを使用して対応可能:

このリストに追加すべき他のアプリケーションをご存知でしたら、お知らせください！

関連リンク