c# - 不确定 C#.NET 中的文件锁定机制

Question

在我的测试环境中，我有两个物理 Windows 7 客户端。两者都可以访问托管在 Windows Server 系统上的网络共享。

客户端分别运行一个应用程序，该应用程序可能会尝试同时对同一文本文件进行操作(读取或写入)。

我想使用 FileInfo.Open()不同场景的实现方法:

场景1:应用程序允许同时读取。如果另一个实例实际上正在写入它，它应该会失败。

我会使用

FileInfo fi = new FileInfo(filePath);
using (FileStream fs = fi.Open(FileMode.Open, FileAccess.Read, FileShare.Read))
{
    // Do some read operations...
    Console.WriteLine("Press ENTER to close file-stream...");
    Console.ReadLine();
}

为此。

场景 2:在尝试写入文件时，仅允许一个实例打开该文件。如果任何其他实例实际上正在读取它，它应该会失败。

我会使用

FileInfo fi = new FileInfo(filePath);
using (FileStream fs = fi.Open(FileMode.Open, FileAccess.Write, FileShare.None))
{
    // Do some write operations...
    Console.WriteLine("Press ENTER to close file-stream...");
    Console.ReadLine();
}

为此。

---

使用上面的代码片段，我的场景按预期工作。尽管我在 using(...) 语句中关闭了一个实例，但该文件仍被“解锁”。

Q1:我想一下应用程序崩溃时是否会发生任何情况，从而导致其他实例对该文件的访问将被拒绝(几次？)。

问题2:打开文件时失去网络连接会发生什么？

Q3:是否有任何理由(另外)使用 FileStream.Lock()和 Unlock()显式锁定和解锁文件的方法？

Q4:服务器系统是否需要任何东西才能运行这种文件锁定方式？

问题5:还有我需要考虑的其他问题吗？

Answer 1

... could anything happen on an application crash

没什么特别的，当操作系统清理弹片并关闭应用程序未关闭的任何文件时，锁定会立即释放。

What happens on loosing network connection while a file is opened?

您将收到运行时异常 IOException。只能通过恢复网络连接并重新打开文件来恢复。网络通常足够可靠，可以考虑不自动执行此操作，YMMV。

Are there any reasons to (additionally) use the FileStream.Lock() ...

没有。这些函数锁定文件数据而不是文件访问。数据库引擎会做的事情。它永远不会应用于文本文件，因为它们是流，并且您永远不知道文件中一行文本的确切文件位置。

Does the servers' system require anything ...

不，这是内置于操作系统中的。

Are there additional points I have to think about?

您可能应该更多地考虑编写文件，必须有人来做。使用 FileShare.None 很简单，但对于文本文件来说往往有点粗糙，特别是当它们是始终保持打开状态的日志文件时。从技术上讲，应用程序可以读取正在写入的文件。由于仅附加文本文件，因此结果往往很好。您可以在写入文件的应用程序中使用 FileShare.Read，并在读取文件的应用程序中使用 FileShare.ReadWrite。不是打字错误。