下面的图像是在ImageShack上托管的1000 x 750像素,~130 kB JPEG.
附加信息
我应该提到每个用户(客户端盒子)将直接在/ Foo共享.由于业务的性质,用户永远不需要同时查看或处理彼此的文档,因此这种性质的冲突永远不会成为问题.访问需要对它们尽可能简单,这可能意味着将驱动器映射到它们各自的/ Foo / username子目录.
此外,除了我的应用程序(内部和服务器上的应用程序)之外,没有人会直接使用FTP目录.
可能的实施
不幸的是,看起来我不能使用WinSCP等现成的工具,因为其他一些逻辑需要与流程密切相关.
我认为有两种简单的方法让我在内部完成上述工作.
>方法一(慢)：
>每N分钟走一次/ Foo目录树.
>使用时间戳的组合(可以通过文件复制工具伪造,但在这种情况下不相关)与校验和进行前一树的差异.
>与异地FTP服务器合并更改.
>方法二：
>注册目录更改通知(例如,使用WinAPI中的ReadDirectoryChangesW,如果使用.NET,则使用FileSystemWatcher).
>记录更改.
>每N分钟与异地FTP服务器合并更改.
问题
由于此同步必须在工作时间进行,因此出现的第一个问题是在非现场上载阶段.
当我在异地传输文件时,我实际上需要阻止用户写入文件(例如,使用带有FILE_SHARE_READ的CreateFile或其他东西),而我正在阅读它.他们办公室的互联网上游速度与他们正在使用的文件大小几乎没有对称,因此他们很可能会回到文件并尝试修改它,而我仍在阅读它.
可能解决方案
解决上述问题的最简单方法是在文件系统的其他位置创建相关文件的副本,并在不受干扰的情况下传输这些“快照”.
这些人将使用的文件(有些将是二进制的)相对较小,可能≤20MB,因此复制(因此暂时锁定)它们几乎是即时的.他们试图在我复制它的同一瞬间写入文件的机会应该接近于零.
不过,这个解决方案似乎很难看,而且我很确定有更好的方法来处理这类问题.
我想到的一件事就是文件系统过滤器,它负责IRP级别的复制和同步,就像一些A / V那样.然而,这对我的项目来说太过分了.
问题
这是我第一次不得不处理这类问题,所以也许我在想太多.
我对干净的解决方案感兴趣,这些解决方案不需要过多地实现其复杂性.也许我错过了WinAPI中优雅处理这个问题的东西？
我还没有决定我会写什么,但我很满意：C,C,C#,D和Perl.
>在数据服务器上创建一个分区,大约5GB以确保安全.
>在C#中创建一个用于监视数据驱动程序/位置的Windows服务项目.
>修改文件后,创建文件的本地副本,其中包含相同的目录结构并放置在新分区上.
>创建另一项服务,执行以下操作：
>监控带宽使用情况
>监视临时分区上的文件创建.
>一次将多个文件(使用线程)传输到FTP服务器,遵守当前时间的带宽使用情况,根据网络流量减少/增加工作线程.
>从已成功传输的分区中删除文件.
所以基本上你有你的驱动器：
> C：Windows安装
> D：共享存储
> X：临时分区
然后你会有以下服务：
> LocalMirrorService – 使用dir结构观察D：并复制到X :.
> TransferClientService – 将文件从X：移动到ftp服务器,从X中删除：
>还可以使用多线程来移动倍数并监控带宽.
我敢打赌,这是你想到的想法,但这似乎是一种合理的方法,只要你的应用程序开发非常好,并且你能够创建一个可以处理大多数问题的可靠系统.
例如,当用户在Microsoft Word中编辑文档时,该文件将在共享上更改,并且可能会被复制到X：即使用户仍在使用它,在Windows中也会有API查看文件句柄是否为仍然由用户打开,如果是这种情况,那么你可以创建一个钩子来观察用户实际关闭文档以便所有编辑完成,然后你可以迁移到驱动器X：.
这就是说,如果用户正在处理文档并且由于某种原因PC崩溃,则文档/文件句柄可能在以后打开文档之前不会被释放,从而导致问题.
