2004 年 7 月 19 日

版本 0.6 (變更記錄)

由 Bryan Ford 提出

摘要

許多應用程式會建立及管理快取目錄，這些目錄包含關於儲存在其他地方的內容的快取資訊，例如快取的網頁內容，或是影像或影片的縮圖版本。為了提升速度和儲存效率，我們通常希望避免備份、封存或以其他不必要的方式複製這些目錄，但要逐一辨識並排除每個這樣的目錄，在資料傳輸操作中相當麻煩。我提出一個極為簡單的慣例，讓應用程式可以可靠地「標記」它們建立的任何快取目錄，供備份系統和其他資料管理工具輕鬆辨識。資料管理工具可依使用者需求遵循或忽略這些標記。

問題描述

許多應用程式會建立及管理某種快取目錄：它們在其中儲存暫存資訊，這些資訊的儲存可提升應用程式效能，但如果遺失，也可以輕易從其他「主要」資料來源重新產生。例如，大多數網頁瀏覽器都有一個快取目錄，用來儲存已下載的網路內容（Mozilla 通常會在 $(HOME)/.mozilla 下方的某個目錄中使用 Cache 這個名稱）。在備份、同步或將使用者的主目錄從一台機器傳輸到另一台機器時，我們通常希望完全避免儲存或傳輸快取目錄，因為：

  • 快取目錄的內容通常沒有長期的封存價值，因為它只是鏡像儲存在其他地方的來源資料，而且常常是以精簡或不完整的格式——例如，只有使用者最近造訪過的網頁部分，或是使用者瀏覽過的圖片的縮圖版本。
  • 快取目錄的大小可能相當可觀——尤其是網頁瀏覽器的快取目錄——可能浪費相當多的備份儲存空間及／或網路頻寬。
  • 快取目錄的內容即使在使用者僅瀏覽或檢視檔案時，也會頻繁變動，這會讓增量備份或同步軟體誤以為目錄樹中有許多頻繁的「虛假變更」，進而破壞增量演算法的效率。
  • 快取目錄中的檔案名稱通常非常隱晦（例如，根據原始來源資料的名稱或內容進行雜湊）。在遍歷使用者主目錄的操作中，看到數千個毫無意義的檔名不斷閃過，至少會令人感到困擾，也可能讓經驗不足的使用者感到困惑或害怕。

然而，有非常多應用程式使用快取目錄。雖然有些正在發展中的標準試圖標準化這些目錄的位置，但大多數應用程式會在不可預測的位置建立自己的快取目錄，並獨立於其他應用程式進行管理。因此，即使是能輕易辨識快取目錄的經驗豐富使用者，也會覺得找出並列出所有適當的 --exclude 選項來進行備份或其他目錄遍歷操作，是一件非常繁瑣的事。有些應用程式，例如較新版本的 KDE，會將快取目錄放在 /tmp 或 /var/tmp，這至少可以部分解決這個問題，因為它們將快取內容完全移出使用者的主目錄。但應用程式或使用者可能有充分理由不希望將這些快取放在 /tmp 或 /var/tmp：例如，這些目錄可能位於不同且空間有限的分區，或是其中的檔案可能被系統清除得太頻繁（例如一天後，或是每次重新開機時），以致無法讓快取有效發揮其預期目的。

檔案系統階層標準 規範了一個系統層級的 /var/cache 目錄，用來存放這類快取資訊，但這個目錄通常不是全域可寫入的，因此只能由系統預先安裝或由系統管理員安裝的應用程式使用。XDG 基礎目錄規格 則建議應用程式將快取建立在由使用者環境變數指定的位置，或是在該環境變數不存在時，建立在使用者主目錄的標準子目錄中。XDG 慣例允許應用程式在沒有特殊權限的情況下運作，但它無法幫助系統層級的備份或資料管理工具可靠地定位個別使用者的快取目錄，因為每個使用者可能在其登入設定檔中以不同方式設定環境變數。

建議的解決方案

鑑於目前對於應用程式應該將快取資訊儲存在何處尚未達成任何完美的共識，我提出一個非常簡單的慣例，至少可以讓這類資訊被有效辨識。無論應用程式決定（或被設定）將其快取目錄放在何處，它都應該在此目錄中放置一個名為： 

CACHEDIR.TAG

的檔案。此檔案必須是普通檔案，而非例如符號連結。此外，此檔案的前 43 個位元組必須包含以下 ASCII 標頭字串： 

Signature: 8a477f597d28d172789f06886806bc55

標頭簽章的大小寫很重要，在 'S' 之前不能有空白或其他字元，且冒號後面正好有一個空格字元（ASCII 碼十進位 32）。標頭字串後面不需要有 LF 或 CR/LF，檔案即可被辨認為有效的快取目錄標記。簽章中的十六進位值恰好是字串 ".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 可能會在某個時間點從上述位置變更，如果／當本提案變得更像正式標準時，但在此情況下，舊位置將保留適當的轉送連結。

應用程式語意

在給定目錄中出現快取目錄標記，表示該目錄的全部內容，包括其下任何及所有子目錄，均由可從其他適當來源材料重新產生的快取資訊組成。建立及／或使用快取目錄的應用程式，應在內容代表快取資訊的最上層目錄中寫入單一快取目錄標記。例如，如果 Mozilla 建立一個名為 $(HOME)/.mozilla/default/dg8t1ih0.slt/Cache 的目錄來存放從網際網路下載的快取內容，它就會在其中建立一個名為 $(HOME)/.mozilla/default/dg8t1ih0.slt/Cache/CACHEDIR.TAG 的快取目錄標記。只需一個快取目錄標記即可標記整個快取內容的子目錄樹。應用程式也應在快取目錄標記消失時重新產生它：例如，如果快取目錄的全部內容被刪除，但目錄本身未被刪除。

資料備份、傳輸或同步軟體（如果已設定如此做）可將目錄中出現快取目錄標記解讀為自動排除該目錄（包括任何子目錄）於備份或傳輸操作之外的指令。我將是否將此「自動排除」行為設為預設值，或僅在使用者明確要求時才採用，交由這類應用程式的設計者決定。短期內採取保守做法可能是合理的，但預設自動排除快取目錄可提升長期效率和易用性。

為了最大限度地防範意外資料遺失，任何內建支援快取目錄標記的工具都強烈建議先驗證它找到的任何名為 CACHEDIR.TAG 的檔案確實是普通檔案，且實際包含上述 43 位元組標頭，然後才認定該檔案確實是快取目錄標記。

使用者友善的檔案管理員和其他目錄階層瀏覽軟體可能也希望注意到目錄中出現快取目錄標記，並告知使用者該目錄的內容是由系統自動管理，且若直接「瀏覽」可能不會有太大意義。

系統管理軟體，例如 du，可能會提供一種方式來定位、加總並回報分割區上所有快取目錄的空間使用量，幫助管理員判斷在檔案系統上使用了多少「軟性」空間，以及在必要時可以輕易釋放多少空間。同樣地，一個工具可能允許管理員清除系統上所有快取目錄，或刪除快取目錄中超過特定「年齡」的檔案。

然而，系統軟體不應僅僅定期自動刪除任意快取目錄中的「舊」檔案。不同的應用程式需要能夠以不同的方式管理其快取；對一個應用程式或系統而言被視為「舊」的快取資料，對另一個應用程式而言可能不被視為「舊」（例如，如果某些資料需要很長時間才能重新產生）。未來本標準可能會擴展，允許應用程式在其快取目錄標記中寫入額外的元資料，為系統工具提供在全域基礎上智慧管理應用程式快取所需的額外資訊。然而，目前引入快取目錄標記的主要目的，僅是讓從一台機器到另一台機器不必要地備份或複製快取資料變得容易避免。

安全性考量

在自動系統備份中「盲目」使用快取目錄標記，可能會增加入侵者或惡意軟體對系統造成的損害。使用者或系統管理員可能 substantially 較不可能注意到惡意插入

CACHDIR.TAG

到重要目錄，而非直接刪除該目錄，例如，導致該目錄的內容從定期備份中被省略。為了降低此風險，備份軟體至少應告知使用者哪些目錄因出現快取目錄標記而被省略。自動增量備份軟體可能會維護一份「已核准」快取目錄清單，並且每當新的快取目錄標記出現時，僅在獲得系統管理員核准後才予以採用。簡言之，為了在面對安全威脅時維持備份的穩健性，快取目錄標記應僅被視為提示，而非「最終定論」來決定什麼應該或不應該被備份。

替代方法

本節討論在制定本提案時所考慮的一些替代方案，以及將提案設計成指定樣式的理由。它以迷你常見問答集的形式呈現，回答最常見的問題。

  • 為什麼不直接標準化應用程式存放快取目錄的位置？ 首先，已經存在多個互相衝突的標準：例如，檔案系統階層標準 規範 /var/cache，KDE 目前使用 /var/tmp，而 XDG 基礎目錄規格 則指定使用使用者可自訂的環境變數，若該環境變數不存在則退回使用使用者主目錄中的 $(HOME)/.cache。即使某個標準最終「勝出」，在標準化應用程式快取的位置與允許使用者自訂之間，仍存在不可避免的緊張關係。XDG 規格清楚地認識到這種緊張關係並加以說明，但其靈活性使得系統層級的工具即使在所有應用程式都符合 XDG 標準的情況下，也很難或不可能可靠地定位每個使用者的快取目錄。

為什麼不直接使用某些作業系統支援的現有「no-backup」或「no-dump」延伸檔案屬性？ 因為只有某些作業系統（通常也只是其中的特定檔案系統）支援這些屬性。任何依賴非可攜式作業系統功能的快取目錄標記慣例，其適用性本質上會受到限制，且不太可能在可攜式應用程式中廣泛採用。應用程式可以自由在可用時支援系統特定的擴充功能，但為了最大效用，我們真正需要一個極為簡單、可攜式的慣例，讓快取應用程式幾乎不費力就能採用，這正是本提案的目的。

為什麼不讓所有網頁瀏覽器都使用相同的快取？ 在多個網頁瀏覽器或其他網頁應用程式之間共用單一網際網路內容快取（所有應用程式可能同時執行），是一個非常有用且重要的目標——但它提出了相當大的技術挑戰，這些挑戰仍在解決中。然而，即使在網頁內容快取達成這種共用時，許多其他應用程式仍會在磁碟上維護其他類型的快取，在其中儲存完全不同類型的資料，例如長時間運算的中間結果，或大型資料集的交換空間。當這些快取的目的完全不同且本質上必須以不同方式管理時，期望應用程式共用快取是不合理的。但期望應用程式至少採用類似此處提出的簡單慣例，使其快取容易被辨識為快取，仍是有用的，且更為實際。

為什麼本提案只支援快取目錄——如果應用程式只有單一檔案作為快取，該怎麼辦？ 因為這種標記方案在這種方式下更簡單且更容易利用，且不會對快取應用程式造成太大負擔。如果您不偏執地檢查快取目錄標記檔案標頭，那麼大多數現有、未修改的備份／封存應用程式都可以透過一些相當簡單的 shell 指令，立即利用這個標記慣例。例如： 

	find . -name CACHEDIR.TAG | sed -e 's/[/]CACHEDIR.TAG$//g' >/tmp/excludes
	tar cvf /tmp/backup.tar --exclude-from=/tmp/excludes .
若要支援在目錄內標記個別檔案，可能至少需要解析文字檔案並掃描其中的檔案名稱，這會讓慣例在一開始就變得更複雜且可能脆弱。而當標準影響到哪些資料會被備份、哪些不會被備份時，我們顯然希望它們盡可能簡單且穩健。

對於那些將所有快取資料都放在單一檔案中的現有快取應用程式，要它們將該快取檔案向下移動一層放入自己的獨立子目錄，並在該新子目錄中寫入快取目錄標記，應該不會太困難。這種輕微的目錄結構變更不應造成任何向後相容性問題，因為根據定義，任何位於舊位置的快取檔案都是可重新產生的，只需刪除或移動即可。而且使用者不會在意，因為他們通常不被期望直接看到或理解應用程式的快取檔案或目錄。

結論

透過採用上述慣例，在適當的地方寫入快取目錄標記，建立及管理快取目錄的應用程式將讓使用者和系統管理員更容易辨識和管理「軟性」儲存區域，這些區域的內容對效能有用，但不需要在機器之間備份或同步。本提案刻意嘗試採用最簡單合理且可攜式的解決方案，以最大化穩健性並最小化採用成本，因此有望最大化其最終廣泛採用的機會。本提案仍然為未來的增強留有空間，在這些增強中，應用程式可能會在其快取目錄標記中包含有關其快取目錄語意和管理的額外有用資訊。

變更記錄

  • 版本 0.6，2019 年 11 月 4 日： 網頁整合與重構；無實質變更。

版本 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 日： 首次公開發布。

應用程式支援狀態

快取應用程式 封存／備份工具
下列應用程式已知會在使用者主目錄中建立及維護某種快取。

目前支援本規格的應用程式：

已收到來自下列開發者的正面回應：

已與下列開發者展開討論：

下列封存工具支援此標記慣例：

其他尚未直接支援快取標記，但可透過適當選項或 shell 指令來支援的封存工具：

請告訴我您所知道的其他應列入此清單的應用程式！

相關連結