没有锁定的优雅文件阅读

Question

白板概述

下面的图像1000 x 750 px, ~130 kB JPEGs托管在ImageShack上.

• 内部
• 全球

---

附加信息

我应该提到每个用户(客户端盒子)将直接在/Foo共享上工作.由于业务的性质,用户永远不需要同时查看或处理彼此的文档,因此这种性质的冲突永远不会成为问题.访问需要对它们尽可能简单,这可能意味着将驱动器映射到它们各自/Foo/username的子目录.

此外,除了我的应用程序(内部和服务器上的应用程序)之外,没有人会直接使用FTP目录.

---

可能的实施

不幸的是,看起来我不能使用现成的工具,如WinSCP,因为其他一些逻辑需要与流程密切相关.

我认为有两种简单的方法让我在内部完成上述工作.

1. 方法一(慢):

   • /Foo每N分钟走一次目录树.

   • 使用时间戳的组合(可以通过文件复制工具伪造,但在这种情况下不相关)和校验和来与前一个树进行差异.

   • 与异地FTP服务器合并更改.

2. 方法二:

   • 注册目录更改通知(例如,使用ReadDirectoryChangesWWinAPI,或FileSystemWatcher使用.NET).

   • 记录更改.

   • 每N分钟与异地FTP服务器合并更改.

由于性能方面的考虑,我可能最终会使用第二种方法.

---

问题

由于此同步必须在工作时间进行,因此出现的第一个问题是在异地上载阶段.

虽然我转移异地文件,我需要有效防止用户写入的文件(例如,使用CreateFile带FILE_SHARE_READ或某事),而我从中读取.他们办公室的互联网上游速度与他们正在使用的文件大小几乎没有对称,所以他们很可能会回到文件并尝试修改它,而我还在阅读它.

---

可能解决方案

解决上述问题的最简单方法是在文件系统的其他位置创建相关文件的副本,并在不受干扰的情况下传输这些"快照".

这些人将使用的文件(有些将是二进制)相对较小,可能≤20MB,因此复制(因此暂时锁定)它们几乎是即时的.他们试图在我复制它的同一瞬间写入文件的机会应该接近于零.

不过,这个解决方案似乎很难看,而且我很确定有更好的方法来处理这类问题.

我想到的一件事就是文件系统过滤器,它负责IRP级别的复制和同步,就像一些A/V那样.然而,这对我的项目来说太过分了.

---

问题

这是我第一次不得不处理这类问题,所以也许我在想太多.

我对干净的解决方案感兴趣,这些解决方案不需要过多地实现其复杂性.也许我错过了WinAPI中优雅处理这个问题的东西？

我还没有决定我会写什么,但我很满意:C,C++,C#,D和Perl.

Answer 1

经过评论中的讨论后，我的建议如下：

• 为了安全起见，在数据服务器上创建一个分区，大约 5GB。
• 使用 C# 创建一个 Windows 服务项目来监视您的数据驱动程序/位置。
• 修改文件后，创建该文件的本地副本，其中包含相同的目录结构并放置在新分区上。
• 创建另一个服务来执行以下操作：
  • 监控带宽使用情况
  • 监视临时分区上的文件创建。
  • 一次传输多个文件（使用线程）到您的 FTP 服务器，遵守当前的带宽使用情况，根据网络流量减少/增加工作线程。
  • 从已成功传输的分区中删除文件。

所以基本上你已经有了你的驱动器：

• C:Windows安装
• D:共享存储
• X:临时分区

那么您将获得以下服务：

• LocalMirrorService- 监视D:并复制到X:目录结构
• TransferClientService- 将文件从X:ftp 服务器移动，从X:
  • 还可以使用多线程来移动倍数并监视带宽。

我敢打赌，这就是您想到的想法，但这似乎是一种合理的方法，只要您确实擅长应用程序开发并且能够创建一个可以处理大多数问题的可靠系统。

例如，当用户在 Microsoft Word 中编辑文档时，该文件将在共享上发生更改，并且X:即使用户仍在处理该文件，该文件也可能会被复制到，在 Windows 中，将有一个 API 查看文件句柄是否仍然打开由用户，如果是这种情况，那么您可以创建一个挂钩来监视用户何时实际关闭文档，以便完成所有编辑，然后您可以迁移到驱动器X:。

也就是说，如果用户正在处理文档并且 PC 由于某种原因崩溃，则文档/文件句柄可能无法释放，直到稍后打开文档，从而导致问题。