boost::filesystem::exists 真的应该为没有媒体的可移动媒体设备抛出异常吗？

Question

我在使用 boost::filesystem::exists 时遇到了一些奇怪的情况。 如果您尝试检查未准备好或没有介质的驱动器上是否存在文件，则会抛出 basic_filesystem_error。 就我所关心的 bfs::exists 的大多数使用而言，如果驱动器未准备好，则意味着该文件不存在。

我可以用 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::exist 调用，但我仍然不满意以这种方式使用 try-catch 是一个好主意。 看来我正在为错过更重要和相关的特殊条件打开大门。

我知道您可以为该函数的非抛出版本重新编译 boost，但我认为这并不能真正避免我的异常处理问题。

以前有人在使用可移动媒体驱动器时遇到过这个问题吗？如果有的话，您是如何克服的？

Answer 1

这是一个错误，可能与以下内容有关：

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

您使用的是最新的 Boost 版本吗？
如果是，请在那里报告另一个错误。 请参阅：

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

Answer 2

我最终通过重新编译 boost 消除了这个烦恼，并将更新的文件系统 .lib 文件重新链接到我的项目

Answer 3

根据文档，exists(file_status s) 返回“status_known(s) && s.type() != file_not_found”。

文档还指出 :

如果底层文件系统在 [file_status] 属性确定期间报告错误：

• 如果错误表明 p 无法解析，就像 POSIX 错误一样 ENOENT [即未找到] ... return file_status(not_found_flag ）。

在我看来，抛出异常并不是预期的行为。 （当您创建 status 对象时，其状态是已知的，并且该状态为 not_found）。

然而，文档继续说：

[注意：此行为的效果是区分知道 p 不存在和无法确定 p 的状态。 这种区别对于用户来说很重要。 --注结束]

这意味着库确实打算区分“文件不存在”和“我无法确定该文件不存在”。 您可能希望联系该库的作者以获得更清晰的声明。

然而，测试文件是否存在是一个竞争条件：当操作系统查看时，该文件可能已经存在，但不能保证它会继续存在； 同样，当操作系统查看时，该文件可能不存在，但不能保证它会继续不存在。 竞争条件可能会产生安全隐患。

相反，打开该文件，然后查看其属性。 文件打开后，操作系统会对哪些内容会发生变化、哪些不会发生变化做出一定的保证。