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

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

之前有没有人遇到过可移动媒体驱动器的问题，如果是这样，你是如何克服它的？

Answer 1

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

The documentation also states that：

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


如果错误表明p无法解决，就好像POSIX错误ENOENT [即未找到] ...返回file_status(not_found_flag)。

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

然而，文件继续说：

[注意：此行为的效果是区分知道p不存在，以及无法确定p的状态。这种区别对用户很重要。 - 后注]

这意味着库打算区分“文件不存在”和“我无法确定该文件不存在”。您可以联系图书馆的作者以获得更清晰的陈述。

但是，测试文件是否存在竞争条件：操作系统看起来可能存在该文件，但无法保证它将继续存在;同样，操作系统看起来可能不存在该文件，但不能保证它不会继续存在。 The race condition can have security implications

相反，打开文件，然后查看其属性。一旦文件打开，操作系统就会改变什么以及什么不会改变做出某些保证。

Answer 2

这是一个错误，可能与：

有关

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

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

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

Answer 3

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

boost :: filesystem :: exists是否真的会为没有媒体的可移动媒体设备抛出异常？

3 个答案: