8

boost :: filesystem::existsを使用しているときに少し奇妙な状況に遭遇しました。準備ができていないか、メディアが入っていないドライブにファイルが存在するかどうかを確認しようとすると、basic_filesystem_errorがスローされます。bfs :: examplesのほとんどすべての使用法に関する限り、ドライブの準備ができていない場合は、ファイルが存在しないことを意味します。

この状態を適切に処理するために、try-catchで呼び出しをラップすることはできますが、少し面倒になり、コードが少し不格好になります。さらに悪いことに、フロー制御にbasic_filesystem_errorの特殊なケースを使用していることを意味します。つまり、その例外の別の理由が発生した場合、それを適切に処理できなくなります。

これが発生する一般的なケースは、ファイルがCDまたはDVDドライブに存在するかどうかを確認しようとした場合です。以前の私のコード:

if( bfs::exists( myFilePath ) )
{
...
}

になる:

bool fileExists( false );
try
{
   fileExists = bfs::exists( myFilePath );
}
catch( bfs::basic_filesystem_error<bfs::path> e )
{
   fileExists = false;
}
if( fileExists )
{
...
}

私は、既存のコードベースのいたるところにこの変更を加えるという考えにあまり夢中になりません。

try-catchをラップする別の関数を作成し、bfs :: exit呼び出しをそれで置き換えることを検討していますが、try-catchをそのように使用するのが良い考えであることにまだ満足していません。より重要で関連性のある例外的な条件を見逃しているため、私は扉を開いているようです。

関数の非スローバージョンのブーストを再コンパイルできることは承知していますが、それによって例外処理の問題が実際に回避されるとは思いません。

以前にリムーバブルメディアドライブでこの問題に遭遇したことがありますか?もしそうなら、どのようにしてそれを克服しましたか?

4

3 に答える 3

5

ドキュメントによると、" " をexists(file_status s) 返しますstatus_known(s) && s.type() != file_not_found

ドキュメントには、次のようにも記載されています。

file_status[ ] 属性の決定中に、基になるファイル システムがエラーを報告した場合:

  • 解決できなかったことを示すエラーの場合、pあたかも POSIX エラーENOENT[つまり、見つからない] のように ... を返しfile_status(not_found_flag)ます。

例外をスローすることは意図した動作ではないように思えます。(オブジェクトを作成すると、statusそのステータスは既知であり、そのステータスは ですnot_found)。

ただし、ドキュメントは次のように続けています。

p[注: この動作の効果は、 が存在しないことを知っていることと、 のステータスを判断できないことを区別することですp。この区別は、ユーザーにとって重要です。--終わりのメモ]

これは、ライブラリ「ファイルが存在しない」と「そのファイルが存在しないと判断できない」を区別しようとしていることを意味します。より明確な声明については、ライブラリの作成者に連絡することをお勧めします。

ただし、ファイルの存在のテストは競合状態です。OS が検索したときにファイルが存在していた可能性がありますが、存在し続けるという保証はありません。同様に、OS が見たときにファイルが存在していなかった可能性がありますが、存在しないままであるという保証はありません。 競合状態は、セキュリティに影響を与える可能性があります

代わりに、ファイルを開いて、その属性を確認してください。ファイルが開かれると、OS は何が変更され、何が変更されないかについて一定の保証を行います。

于 2009-06-30T22:13:15.787 に答える
2

これはおそらく次のようなバグです:

https://svn.boost.org/trac/boost/ticket/2725

最新の Boost バージョンを使用していますか? はいの場合は、そこで別のバグを報告してください。見る:

http://www.boost.org/support/bugs.html

于 2009-06-30T21:05:35.830 に答える
0

ブーストを再コンパイルすることで最終的にこの動揺を取り除き、更新されたファイルシステムの.libファイルをプロジェクトに再リンクしました

于 2020-03-26T07:53:08.293 に答える