EDIT : Windows の精度 (pingw33n に感謝)
次の場合に no を取得するのは完全に正常ですException
。
- ファイルを開く
- あなたまたは他の誰かがファイルを削除します
- ファイルへのアクセス、削除前のファイルの読み取り、または書き込み
実際、ファイルを削除しても、ファイル自体には何の影響もありません。削除されるのは、ディレクトリ内のエントリです。そして、次の場合にのみ、ファイルは実際に破棄されます (そして、ディスク上で使用されているセクターは解放されます)。
- それ以上のディレクトリエントリはそれを指していません
- ファイル記述子が開いたままにしない
したがって、要求したバイトがメモリにバッファリングされていなくても、ファイル システムはディスクから取得する方法を認識しています。ちなみに、一時ファイル、つまり最終終了時に削除されるファイルを作成するのはよくあるパターンです。
もちろん、 merlin2011 が提案することを実行できます。つまり、パスを介してファイルの存在をテストします。ただし、ファイルが削除されてから再度作成されることを知っておく必要があります。パス (ファイルを開くために使用されたパス) は存在しますが、まったく別のオブジェクトを指しています。
したがって、ファイルが実際にディレクトリの内容を反映することが本当に必要な場合は、ファイルを開いたままにすることはできず、アクセスするたびに再度開く必要があります...これは公正なオプションではありません。
- ディレクトリおよびファイル システムへの変更を無視します。ファイルがあり、それを使用します。これが正しいユースケースはたくさんあります。
- ディレクトリはあなたのものであり、他の誰もその中のファイルを削除してはならないことをドキュメントに記載してください。結局のところ、管理者がシステムを破壊したりアプリを強制終了したりするのを防ぐことはできません。
これはすべての通常のファイルシステム、Linux やその他の Unix 系のシステム、NTFS などすべてに当てはまります。CPM や FAT などの古いファイルシステムにも当てはまるかどうかはわかりませんが、現在は本番環境では使用されていません。 :-)。しかし、Windows では、Java アプリケーションで現在開いているファイルを削除することはできません。
2つの質問に正確に答えるには:
- あなたのポインタはぶら下がっていませんが、まだ実際のファイルを指しています(他の誰もそれを見ることができなくても)
- ファイルにアクセスできない場合 (ディスクまたは接続への物理的な損傷、ファイル システム エラーなど) は、例外がスローされます。ただし、エントリのみが削除された場合、ファイルには引き続きアクセスできます