下面的图像1000 x 750 px, ~130 kB JPEGs托管在ImageShack上.
我应该提到每个用户(客户端盒子)将直接在/Foo共享上工作.由于业务的性质,用户永远不需要同时查看或处理彼此的文档,因此这种性质的冲突永远不会成为问题.访问需要对它们尽可能简单,这可能意味着将驱动器映射到它们各自/Foo/username的子目录.
此外,除了我的应用程序(内部和服务器上的应用程序)之外,没有人会直接使用FTP目录.
不幸的是,看起来我不能使用现成的工具,如WinSCP,因为其他一些逻辑需要与流程密切相关.
我认为有两种简单的方法让我在内部完成上述工作.
方法一(慢):
/Foo每N分钟走一次目录树.
使用时间戳的组合(可以通过文件复制工具伪造,但在这种情况下不相关)和校验和来与前一个树进行差异.
与异地FTP服务器合并更改.
方法二:
注册目录更改通知(例如,使用ReadDirectoryChangesWWinAPI,或FileSystemWatcher使用.NET).
记录更改.
每N分钟与异地FTP服务器合并更改.
由于性能方面的考虑,我可能最终会使用第二种方法.
由于此同步必须在工作时间进行,因此出现的第一个问题是在异地上载阶段.
虽然我转移异地文件,我需要有效防止用户写入的文件(例如,使用CreateFile带FILE_SHARE_READ或某事),而我从中读取.他们办公室的互联网上游速度与他们正在使用的文件大小几乎没有对称,所以他们很可能会回到文件并尝试修改它,而我还在阅读它.
解决上述问题的最简单方法是在文件系统的其他位置创建相关文件的副本,并在不受干扰的情况下传输这些"快照".
这些人将使用的文件(有些将是二进制)相对较小,可能≤20MB,因此复制(因此暂时锁定)它们几乎是即时的.他们试图在我复制它的同一瞬间写入文件的机会应该接近于零.
不过,这个解决方案似乎很难看,而且我很确定有更好的方法来处理这类问题.
我想到的一件事就是文件系统过滤器,它负责IRP级别的复制和同步,就像一些A/V那样.然而,这对我的项目来说太过分了.
这是我第一次不得不处理这类问题,所以也许我在想太多.
我对干净的解决方案感兴趣,这些解决方案不需要过多地实现其复杂性.也许我错过了WinAPI中优雅处理这个问题的东西？
我还没有决定我会写什么,但我很满意:C,C++,C#,D和Perl.
