One of our customers has a 2008R2 Datacenter Edition SP1 file server, and runs our application on several machines which access these files. There is a specific situation when a file is present (in a fileserver folder) which each machine opens (for read and write) every 20 or 30 seconds, decides it cannot process it, and immediately closes again. A completely separate interlock mechanism prevents multiple nodes from even attempting to open the file concurrently.
This works well when all the accessing machines are running Server 2008R2, even though the server open files list shows the file as permanently open. But when a Windows 2003 machine starts up running the same application and the same interlock, it always fails to open the file with a sharing violation, and this machine is also unable to delete the file. Closing all the 2008R2 accessors causes the file to disappear from the file server open files list and allows the Windows 2003 machine to be able to open the file, and delete it. However PROCMON reveals no contact with the file as the accessor is closed.
It's as if there is a private code which the 2008R2 machines and server use to keep the file in a pseudo-open state, and which 2003 is not aware of, so it thinks the file is really open. It cannot really be permanently open because the 2008 nodes are regularly opening it. If my theory is correct, how could our customer fix it?
Best Answer
I'm immediately suspicious that there's some lossage in the interoperability of SMB and SMB2 clients accessing the same file. You could, at least, try to isolate the behavior to being an SMB/SMB2 interoperability problem by disabling SMB2 on the Windows Server 2008 R2 clients. (It's a bad thing to do, from a performance standpoint, but it might isolate the problem enough to make the determination that removing the Windows Server 2003 clients is the "solution".)
Can you describe how your "interlock" protocol functions?