The fucking [tag]DFS[/tag] is going to be the end of me. It’s great, and awesome but only when you make sure that everyone is connected to the single server. Otherwise you get sharing violations and all hell breaks loose. For example, consider this scenario:
- Person A opens a spreadsheet X on the [tag]network share[/tag] S and DFS opens a connection to the file on Server 1.
- Person B opens X on S, and this time DFS tries to do [tag]load balancing[/tag], and B ends up on Server 2.
- Both A and B modify the spreadsheet and then save it. No one gets [tag]sharing violation[/tag] errors? What happened?
The key to this mystery is the core mechanic of DFS which is [tag]replication[/tag]. DFS does not care about concurrent writes. It simply makes sure that the file with the most recent timestamp is copied over to the other server immediately. So, in a conflict situation, whoever saves last wins.
What is the solution here? Make sure that everyone is using S on Server 1, and that there is no load balancing. This is the only way to avoid [tag]concurrency[/tag] issues.
That said, I spent the whole morning digging through the DFS ConflictAndDeleted folder, and the staging area files looking for a spreadsheet that did not save last night. I could not find it, so I called in reinforcements to help me figure out the ins and outs of the DFS setup. In the end we had two people looking for this file for several hours, trying to figure out why and how did we get this conflict.
We finally found it… Guess what? It turns out that the user simply saved it under a different name, and then forgot. We spent hours blaming poor DFS when obviously [tag]PEBKAC[/tag]. Aaaagh!