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：我想一下，如果应用程序崩溃可能发生任何事情，那么其他实例访问该文件将被拒绝（几次？）。

Q2：在打开文件时丢失网络连接会发生什么？

问题3：是否有任何理由（另外）使用FileStream.Lock()和Unlock()方法明确锁定和解锁文件？

问题4：服务器的系统是否需要采取任何措施来实现文件锁定的运行？

问题5：我还需要考虑其他问题吗？

Answer 1

......在应用程序崩溃时可能发生任何事情

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

打开文件时丢失网络连接会发生什么？

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

是否有任何理由（另外）使用FileStream.Lock（）...

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

服务器系统是否需要任何内容......

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

我还有其他要点吗？

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

Answer 2

您所指的文件锁定是在操作系统级别完成的。因此，如果您的应用程序崩溃，错误等等，它将释放该文件。这适用于Q1和Q2（尽管Q2取决于网络拓扑和后备存储）。注意锁定文件可能会导致启用缓冲的后备存储出现奇怪的性能问题。 Q3，Lock，Unlock指的是没有文件锁，而是文件中的字节。这是一个完全不同的概念，它将导致你在NAS类型存储上的奇怪行为 Q4，就像我之前所说的那样是操作系统级别的概念。 Q5。想想一个更好的管理方法，使用文件是一个相对古老的概念，然而，在网络上的多台计算机之间共享文件，恕我直言，正在要求奇怪的头部刮擦行为。现代文件存储不适合这个概念，并且通过缓冲，延迟和安全性变得具有挑战性。尽量避免使用它。如果做不到这一点，请确保优化您的应用程序，以便尽快打开文件，写入，关闭和刷新流。

不确定C＃.NET中的文件锁定机制

2 个答案: