PathCapabilitiesPathCapabilities 介面提供一種方式，可透過程式查詢 FileSystem、FileContext 或其他實作類別的執行個體在特定路徑下提供的作業。
public interface PathCapabilities {
boolean hasPathCapability(Path path, String capability)
throws IOException;
}
此處有許多目標
O(data)）、目錄重新命名為非原子性等。功能定義為字串，並區分為「共用功能」和特定儲存體的非標準功能。
共用功能全部定義在 fs.capability. 前綴下。
請參閱 org.apache.hadoop.fs.CommonPathCapabilities 的 javadocs 以取得這些功能。
個別檔案系統可能會提供自己的功能集，可以探查這些功能。這些功能集必須以 fs. + 檔案系統架構 + .capability 開頭。例如 fs.s3a.capability.select.sql；
boolean hasPathCapability(path, capability)探查在特定路徑下提供特定功能的執行個體。
if fs_supports_the_feature(path, capability): return True else: return False
傳回：如果特定功能可用，則傳回 True。
檔案系統執行個體不得傳回任何功能的 True，除非已知該特定執行個體支援該功能。因此，如果呼叫者探查某個功能，則可以假設特定的功能/語意可用。
如果探查傳回 False，則可能表示下列其中一項：
此謂詞預期成本低。如果需要遠端呼叫（路徑/連結解析除外），它應該推論該功能的可用性不明，並傳回 False。
此謂詞也必須沒有副作用。
路徑的有效性 沒有必要檢查路徑是否存在；參數存在，以便任何將作業轉發到其他檔案系統（例如 viewfs）的檔案系統，都能解析並將其轉發到巢狀檔案系統。請將呼叫視為相對輕量級。
因此，儘管檔案系統宣告它在某個路徑下支援某個功能，但實際呼叫該作業可能會因為其他原因而失敗。
例如，儘管檔案系統可能在某個路徑下支援 append()，但如果在目錄上呼叫，則呼叫可能會失敗。
也就是說，對於路徑 root = new Path("/")：功能呼叫可能會成功
fs.hasCapabilities(root, "fs.capability.append") == true
但隨後對該特定路徑的作業呼叫可能會失敗，因為根路徑是目錄
fs.append(root)
類似地，不會檢查呼叫者是否有權限執行特定作業：僅因為某個功能在該路徑上可用，並不表示呼叫者可以執行該作業。
因此，hasCapabilities(path, capability) 偵測宣告作業不會因不受支援而遭拒絕，而不是呼叫者允許在該路徑上進行特定呼叫。
可用性期間
隨著遠端儲存庫狀態變更，路徑功能也可能變更。這可能是由於檔案系統的本地狀態變更（例如，符號連結或掛載點變更），或其功能變更（例如，由於作業變更、系統升級等，導致功能可用/不可用）。
必須呼叫以確定可用性的功能
客戶端連接器可能知道某些作業，並相信這些作業可用，但實際上在呼叫時可能會失敗，這是因為遠端儲存庫的狀態和權限，而此狀態只能透過嘗試產生副作用的作業來確定。
符號連結和本地檔案系統就是一個關鍵範例。檔案系統宣告它支援此功能，除非符號連結已明確停用，否則在呼叫時實際上可能會失敗。
實作人員不得為任何無法保證支援的功能傳回 true。傳回 true 表示檔案系統的實作/部署根據檔案系統客戶端的最佳知識，提供查詢的所需作業和語意。
基於效能考量，實作人員不應檢查路徑是否存在，除非需要解析路徑中部分的符號連結，以確定功能是否存在。FileContext 和 viewfs 需要這樣做。
個別檔案系統不得單方面定義新的 fs.capability 前綴功能。相反地，他們必須執行下列其中一項動作
fs.capability 值。fs.hdfs.