ファイルを開こうとして例外をキャッチせずに、ファイルが使用されているか、他のプロセスによって開かれていないかを確認する方法はありますか? そのようなことをテストするサービス方法はありませんか?
4 に答える
あったとしても、最初のチェックと実際のオープン/アクセス試行の間にファイルが利用できなくなったという競合状態を処理するために例外をキャッチする必要があるため、あまり役に立ちません。
事前の防御チェックに勝る利点は思いつきません。不要なコードの重複が発生するだけです。
そのような関数があった場合IsFileAccessible
、おそらく、ファイルを開こうとして失敗をキャッチし、結果を返す巨大な try/catch ブロックとして実装されるでしょう。
ファイルを開こうとせずに開くことができるかどうかをテストできますか?
.net フレームワークは、その下にある Windows API と同様に、そのような機能を提供しません。ファイルを開くことができるかどうかを知りたい場合は、ファイルを開いて失敗を確認する必要があります。
try catch を回避する (ただし、開こうとすることを意味する) 興味深い方法は、LockFile()またはCreateFile()関数です。
HANDLE WINAPI CreateFile(...)
関数が成功した場合、戻り値は、指定されたファイル、デバイス、名前付きパイプ、またはメール スロットへの開いているハンドルです。
関数が失敗した場合、戻り値は INVALID_HANDLE_VALUE です。拡張エラー情報を取得するには、GetLastErrorを呼び出します。
BOOL WINAPI LockFile(...)
関数が成功した場合、戻り値はゼロ以外 (TRUE) です。
関数が失敗した場合、戻り値はゼロ (FALSE) です。拡張エラー情報を取得するには、GetLastErrorを呼び出します。
これは、呼び出しプロセスによる排他的アクセスのために指定されたファイルをロックし、失敗すると、エラー情報をスレッドの最後のエラーに書き込みます。これは、GetLastError関数を使用して取得できます。
unlockFile と OpenFile の間で別のプロセスがファイルをロックする可能性は依然として考えられますが、ファイルを開く必要がある瞬間までファイルをロックしておくことで、この期間を最小限に抑えることができます。
この男を.net 4.5に実装できますが、多くのオーバーヘッドが含まれます http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx