open、read、および close を使用して基本的なファイル読み取りを行っています (ファイルはアクセス モード O_RDONLY で開かれます)。
ファイルを閉じるときが来たら、ファイルが適切に閉じられていることを確認するために、考えられるファイル クローズ エラーを処理する良い方法が思いつきません。
助言がありますか?
open、read、および close を使用して基本的なファイル読み取りを行っています (ファイルはアクセス モード O_RDONLY で開かれます)。
ファイルを閉じるときが来たら、ファイルが適切に閉じられていることを確認するために、考えられるファイル クローズ エラーを処理する良い方法が思いつきません。
助言がありますか?
私の経験close
上、失敗しても成功します。これにはいくつかの理由があります。
close
一部のオペレーティング システムで障害が発生し始めた大きな理由の 1 つは、AFS にあると思われます。AFS は 80 年代の分散ファイル システムで、興味深いセマンティクスを備えていました。すべての書き込みはローカル キャッシュに行われ、ファイルを閉じるとデータがサーバーに書き込まれました。AFS はまた、一定期間後に有効期限が切れるトークンを使用して暗号で認証されました。そのため、トークンが有効である間にファイルに行ったすべての書き込みが行われたが、close
実際にはファイル サーバーと通信した興味深い状況に陥る可能性があります。キャッシュが失われました。これが理由ですclose
問題が発生したことをユーザーに伝える必要がありました。ほとんどのファイル エディタはこれを正しく処理しますが (たとえば、emacs はバッファーをダーティでないとマークすることを拒否します)、これを処理できる他のアプリケーションはほとんど見たことがありません。
そうは言っても、close
とにかく失敗することはできません。, (witch close-on-exec ファイル記述子) のclose
間は暗黙的であり、コアをダンプするクラッシュします。失敗できない状況です。ファイル記述子を閉じることができなかったという理由だけで、クラッシュが失敗することはありません。失敗したらどうする?クラッシュ?クラッシュに失敗したら?その後、どこに逃げますか?また、エラーをチェックする人はほとんどいないため、exit
exec
exit
exit
close
失敗が一般的である場合、ファイル記述子のリークと情報漏えいが発生することになります (特権のないプロセスを生成する前にファイル記述子を閉じることができなかった場合はどうなるでしょうか?)。これはオペレーティング システムが許可するには危険すぎるため、私が調べたすべてのオペレーティング システム (*BSD、Linux、Solaris) は、基になるファイル システムのクローズ操作が失敗した場合でも、ファイル記述子をクローズします。
実際には、これは呼び出しclose
て、返されるエラーを無視することを意味します。編集者のようにうまく処理できない場合は、ユーザーにメッセージを送信し、ユーザーに問題を解決してもらい、ファイルを再度開いてもらい、データを書き留めてから再度閉じるようにします。ループなどで自動的に何もしないでください。エラーはclose
、アプリケーションでは制御できません。