PathCapabilitiesPathCapabilities インターフェースは、FileSystem、FileContext、または他の実装クラスのインスタンスによって、特定のパスで提供される操作をプログラムでクエリする方法を提供します。
public interface PathCapabilities {
boolean hasPathCapability(Path path, String capability)
throws IOException;
}
ここにはいくつかの目標があります。
O(data)である、ディレクトリの名前変更がアトミックではないなど）を公開できるようにします。機能は文字列として定義され、「共通機能」と特定のストア用の非標準機能に分割されます。
共通機能はすべて、プレフィックス fs.capability. の下に定義されています。
これらについては、org.apache.hadoop.fs.CommonPathCapabilities の Javadoc を参照してください。
個々のファイルシステムは、プローブできる独自の機能セットを提供してもよいです。これらは、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.）。