c# - 如何知道文件系统是否只读(.NET 标准)？

Question

我有一个读取文件的函数，如果它不存在，它会创建并填充它。然而，这是在 .NET 标准库中，并从返回以下错误的 AWS Lambda 函数调用:

"Read-only file system"

我如何确定文件系统在代码中是只读的，以便我可以跳过文件创建以及在这种情况下？

编辑:我的问题不同于 Is there a way to check if a file is in use .这个问题是关于在保存文件之前尝试读取文件的问题。我在问如何知道文件系统是否不允许我保存文件(由于文件系统的限制)

Answer 1

一般来说，对于与文件系统有关的几乎一切，诀窍是记住它们是易变的，因此答案就是尝试 无论你想做什么，如果失败就处理异常。

为了理解我所说的“ volatile ”的意思，假设您有一些神奇的 Path.IsReadOnlyFileSystem() 方法可以完全满足您的需求。所以你想运行一些这样的代码:

if (!Path.IsReadOnlyFileSystem(fileIWantToCreate))
{
    using(var sw = new StreamWriter(fileIWantToCreate))
    {
        //fill file here
    }
}

但是您的 AWS 云中发生了一些事情，迫使该服务进入只读模式。它就发生在这里:

if (!Path.IsReadOnlyFileSystem(fileIWantToCreate))
{
    /* <==== AWS goes read-only here ====> */
    using(var sw = new StreamWriter(fileIWantToCreate))

您的神奇方法完美地完成了它的工作。在您调用该方法的那一刻，文件系统仍然允许写入。不幸的是， volatile 文件系统意味着您不能信任从一个时刻到下一个时刻的操作(并且非 volatile 文件系统对您保存数据不会有太大好处)。因此，您可能会想采用这样的模式:

try 
{
    if (!Path.IsReadOnlyFileSystem(fileIWantToCreate))
    {
        using(var sw = new StreamWriter(fileIWantToCreate))
        {
            //fill file here
        }
    }
}
catch(  )
{
    // handle the exception here
}

现在很明显无论如何您都必须处理异常。if() 条件在实际功能方面并没有真正获得任何好处。它所做的只是增加代码的复杂性。

即便如此，仍有一种倾向认为保持 if() 条件可以通过保存异常处理程序和磁盘访问来获得性能优势。 这种信念是有缺陷的。

if() 条件在检查文件系统状态时实际上添加 磁盘访问。此外，此成本会在每次 执行时添加。保持 if() 条件确实保存异常处理程序，但仅在初始访问失败的情况下。诚然，展开堆栈来处理异常是所有计算机科学中您可以执行的最昂贵的操作之一。这就是“不要对正常控制流使用异常”口号背后的“原因”。但是，磁盘访问是为数不多的对性能远比差的事情之一。

总而言之，我们有时会有一个异常处理程序堆栈展开，而每次都有额外的磁盘访问。从性能的角度来看，很明显没有 if() 条件会更好。出于正确性原因，我们不需要 if() 条件，出于性能原因，我们不需要它......再次提醒我为什么我们有它？更好的模式会完全跳过该 block ，如下所示:

try
{
    using(var sw = new StreamWriter(fileIWantToCreate))
    {
        //fill file here
    }
}
catch( )
{
    // handle the exception here
}

因此神奇的 IsReadOnlyFileSystem() 方法不是必需的，甚至没有帮助。

这并不是说该方法不存在(我不认为它是 .Net Standard 的一部分，但根据您的平台，您可能会调用一个较低级别的构造)。只是这不是一个特别好的主意。