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

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

客户端分别运行一个应用程序，该应用程序可能同时尝试对同一文本文件进行操作（读或写）

我想用这个方法来实现不同的场景：

场景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();
}

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();
}

为此

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

我会用

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();
}

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();
}

为此

---

使用上面的代码片段，我的场景可以按预期工作。即使我在

中使用（…）

语句关闭了一个实例，该文件还是被“解锁”

Q1:我考虑应用程序崩溃时是否会发生任何情况，这样其他实例对该文件的访问就会被拒绝（几次？）

Q2:打开文件时，如果失去网络连接，会发生什么情况

Q3:是否有任何理由（另外）使用和方法显式锁定和解锁文件

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

---

Q5:我还需要考虑其他问题吗？

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

。。。应用程序崩溃时会发生什么

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

打开文件时，如果网络连接断开，会发生什么情况

您将得到一个运行时异常，IOException。只有通过恢复网络连接并重新打开文件才能恢复。网络通常是足够可靠的，不考虑自动地这样做，YMMV。< /P> 是否有任何理由（另外）使用FileStream.Lock（）

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

服务器的系统需要什么

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

我还需要考虑其他几点吗

---

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

考虑一下，如果有人试图用您无法控制的程序打开/修改文件，会发生什么情况。他们不会总是使用您期望的锁类型。@CathalMF很好。但我认为，在我的情况下，这取决于最终用户不这样做。人们（希望）知道他们在做什么：-）我们都希望我们的用户知道他们在做什么。但总有那么一个人！！只要确保你的应用程序不会爆炸，如果有人打开的文件中有一些共享权限和读/写的组合。谢谢你的回答。你能给我解释一下，或者共享一个链接，为什么系统B知道系统a实际上在网络共享上处理一个文件？系统B不知道，它会询问任何拥有该文件的系统。网络重定向器的作业。我不知道有任何链接。此外，这可能在我前面的问题中得到回答，如果锁定系统立即崩溃（关闭），文件如何识别它不再被锁定？文件什么都不知道，操作系统知道。它通过句柄跟踪打开的文件，并仲裁对底层文件对象的访问。关闭文件会告诉操作系统停止跟踪。