如何锁定多用户文件管理系统中的文件

Question

我有一个程序（部署到每个用户计算机的副本），以便用户将文件存储在具有压缩（CAB文件）的集中式文件服务器上。

添加文件时，用户需要将文件提取到自己的磁盘上，添加文件并将其压缩回服务器。因此，如果两个用户同时处理相同的压缩文件，则稍后上载的文件将会更早更新并导致数据丢失。

我的策略是防止这种情况出现在用户提取压缩文件之前，程序会检查服务器上是否存在指定的临时文件。如果没有，程序会创建这样的临时文件以防止其他用户的干扰，并且会在上传后删除临时文件;如果是，程序将等待，直到临时文件被删除。

有没有更好的方法来做到这一点？并且会经常创建和删除空文件损坏磁盘？

Answer 1

查看FileStream.Lock方法。从MSDN引用：

防止其他进程读取或写入FileStream。
...

锁定文件流的范围使锁定进程的线程可独占访问该文件流的范围。

Answer 2

创建临时文件来标记锁是一种可行且广泛使用的选项（并且不会损坏磁盘）。另一个选择是专门打开压缩文件（或让其他进程只读取文件但不写入文件），并在用户使用文件内容时保持打开文件。

Answer 3

而且会经常创建和删除空文件损坏磁盘吗 ？

不可以。如果您使用的是固态磁盘，则可以执行的写入数量（这是FLASH的继承限制）存在理论上的限制。但是，你难以置信地达不到这个限制。

有没有更好的做这个

好方式，我会去了解这个不同：

写Windows服务处理所有磁盘访问，并让您的客户端应用交谈的服务。因此，当客户端需要检索文件时，它会打开一个到您的服务的套接字连接并请求该文件，并将其保存在内存中或将其保存到本地磁盘。在客户端的本地文件副本（解压缩，添加/删除/更新文件，重新压缩等）上执行任何修改，并且当操作完成并准备好保存（或以源代码控制术语提交）时，更改，打开另一个连接到服务应用程序（在服务器上运行）的套接字连接，并将新文件内容作为二进制流发送给它。

然后服务应用程序将处理加载并将文件保存到磁盘。这也给了你很多额外的功能 - 服务器可以跟踪以前的版本（甚至可能将每个版本提交给svn或其他源代码管理系统），提供元数据，如最新版本等。

现在我正在考虑它，你可能会更好的只是将svn接口集成到你的应用程序中。 SharpSVN is a good library for this.

Answer 4

有没有更好的方法来做到这一点？

是的。从你在这里写的内容来看，这听起来像你正在重新发明revision control。 也许你可以使用一些现成的版本控制系统？ 或者至少可以重复使用这些系统的一些代码？ 或者你至少可以了解一些有关这些系统面临的问题，如何修复显而易见的问题导致非显而易见的问题，并试图建立一个至少可以工作的系统？

我的理解是，版本控制系统经历了几个阶段（请参阅原始wiki上的 "Edit Conflict Resolution"，波特兰模式存储库）。 大致按时间顺序排列：

1. 主版本存储在服务器上。最后保存的胜利，导致神秘的数据丢失，没有任何警告。
2. 主版本存储在服务器上。当我将副本拉到我的机器上时，系统会在服务器上创建一个锁定文件。当我将更改推送到服务器（或取消）时，系统会删除该锁定文件。没有人可以更改服务器上的这些文件，所以我们修复了“神秘的数据丢失”问题，但是当我需要编辑一些其他人在离开长假期之前签出的文件时，我们感到无限的沮丧。
3. 主版本存储在服务器上。首先保存胜利（“乐观锁定”）。当我从服务器上获取最新版本时，它包含某种版本号。当我稍后将我的编辑推送到服务器时，如果我拉出的版本号与服务器上的当前版本不匹配，则其他人先切入并改变了我的前提，并且系统给出了某种礼貌信息告诉我这件事。理想情况下，我从服务器上获取最新版本，并仔细地将其与我的版本合并，然后将合并后的版本推送到服务器，并且一切都很美妙。唉，常常，一个不耐烦的人拉动最新版本，用“他的”版本覆盖它，并推动“他的”版本，导致数据丢失。
4. 每个版本都存储在服务器上，并且链接不中断。 （集中版本控制像TortoiseSVN就是这样）。
5. 每个版本都存储在每个本地工作目录中;有时链条分成两条链;有时两条链会合并成一条链。 （像TortoiseHg这样的分布式版本控制工具就是这样的）。

因此，听起来好像你正在做其他人从第一阶段转到第二阶段时做的事情。我想你可以慢慢地在每个阶段工作。 或者也许你可以跳到第4或第5阶段并节省每个人的时间？