我们的客户之一有一个2008R2数据中心版SP1文件服务器，并在多台访问这些文件的机器上运行我们的应用程序。 当每个机器每隔20或30秒打开（读写）文件时，存在一个特定的情况（在文件服务器文件夹中），决定不能处理它，并立即closures。 完全独立的联锁机制可以防止多个节点甚至试图同时打开文件。
当所有访问机器都运行Server 2008R2时，即使服务器打开文件列表显示文件已永久打开，也能正常工作。 但是，当Windows 2003计算机启动运行相同的应用程序和相同的互锁，它总是无法打开共享冲突的文件，并且这台机器也无法删除该文件。 closures所有2008R2访问器将导致文件从文件服务器打开文件列表中消失，并允许Windows 2003计算机能够打开文件并将其删除。 但是，PROCMON在访问者closures时显示没有与文件的联系。
就好像有一个私人代码，2008R2机器和服务器用来保持文件处于伪开放状态，而哪个2003不知道，所以它认为文件是真正开放的。 它不能真正永久开放，因为2008年的节点经常打开它。 如果我的理论是正确的，那么我们的客户怎么解决呢？
我立即怀疑SMB和SMB2客户端访问同一文件的互操作性有所损失。 至less，您可以通过禁用Windows Server 2008 R2客户端上的SMB2来尝试将行为隔离为SMB / SMB2互操作性问题。 （从性能angular度来看，这是一件坏事，但它可能会将问题孤立起来，以确定删除Windows Server 2003客户端是否是“解决scheme”。）
你能描述一下你的“互锁”协议的function吗？
埃文的build议是坚实的，所以我会首先关注。 如果您没有得到任何关注，那么您应该了解一些有关Windows Server 2003的知识：对文件共享执行某些types的活动时，rdbss.sys中存在严重的竞争条件/locking错误。
症状和情况可能会有所不同，如果文件争用足够大，甚至可能会lockingWindows 2003服务器。 我不知道为什么它不会更频繁地出现，但是我确实很难做出类似的事情。 另外请注意，即使使用独立的locking机制，也可能有其他进程访问这些文件，如防病毒。
这里是kb的文章。 不要被相当无关的标题分心。
http://support.microsoft.com/kb/960092
http://support.microsoft.com/kb/983169
为了更好地了解实际发生的情况，当发生这种情况时，您需要在2003服务器上执行networking数据包捕获。 SMB的NetMonparsing器实际上相当不错，你通常可以发现一个锁争用问题。