我们有几个DOS应用程序（Clipper）在文件服务器上共享dbase文件。 这些应用程序在XP下运行。 对于Netware来说，这已经工作了大约二十年，而Samba（成员服务器）多年来一直没有问题。
几个星期前，我将openSUSE从11.4（samba-3.6.3）升级到了12.2（samba-3.6.7），并更换了硬件（带有6 GiB RAM的AMD E-450）。 更糟糕的是（从debugging的angular度来看）大约在那个时候，交换机被改变了（从100Mbit到48端口的Gb交换机）。
从那以后（现在还不清楚，究竟是因为用户没有立即告诉我们而发生什么改变…），一些用户面临着某些DOS应用程序严重的问题，这些应用程序不能精确复制。 这似乎是关于访问权限或（更可能）文件locking。 据我们所知，这些应用程序在文件上执行字节范围locking。 我不知道是否（以及如何）从samba获得这种debugging信息。 访问这些文件没有一般问题。 Oplocks被启用（禁用是不可接受的，也不能解决问题）。
然后我改变了服务器结构：早期的Samba在真正的硬件上运行。 我把主机操作系统作为一个简单的虚拟机主机来安装），然后把Samba安装到一个虚拟机上，使用openSUSE 11.4安装，这个安装在以前没有任何问题。 问题并没有消失。 Samba虚拟机的升级（到12.2）似乎已经变得更糟了。 普通的Windows共享访问似乎没有受到任何这些configuration的影响。 ifconfig显示大约每4000个RX数据包中有一个被丢弃在接口上。
任何想法，无论是对于真正的问题还是对于精确的Sambadebugging/跟踪来说，Samba和XP客户端之间的通信究竟是什么问题？
没有更好的想法，我可能会首先尝试不同的网卡。 多年前，我已经解决了一个（一般的，不是DOS相关的）Samba问题。
确保从客户端angular度隔离错误。 在服务器端进行debugging之前，您必须了解客户端要做什么。
请注意，DOS不知道关于Oplocks的任何事情 – 所以我真的不知道他们是如何影响你这个特定的问题。 当一个客户端用标准的DOS系统调用这个文件locking一个文件时，它将被locking为一个整体。 然后第二个客户端将遇到所述的“错误5”。
由于这个工作较早，它怀疑应用程序不使用标准的locking机制，而是使用它自己的 – 不pipe它是什么。 这意味着一些其他进程locking文件。 您可以使用lsof来查找打开的文件（锁）。