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

根据文档，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。这种区别对用户很重要。-尾注]

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

但是，测试文件的存在是一个竞争条件：当操作系统看时，该文件可能已经存在，但不能保证该文件将继续存在。同样，在看操作系统时，该文件可能不存在，但不能保证该文件将继续不存在。 竞争条件可能会带来安全隐患。

而是打开文件，然后查看其属性。打开文件后，操作系统将对什么会更改和什么不会更改做出某些保证。

Answer 2

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

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

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

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