DFS File Share- File Conflicts and lost data

I already went through scenarios where we installed DFS and made it highly available. In my article about clustering DFS I mentioned that downside of DFS cluster is potential data corruption and loss due to ability that two people work on the same file at the same time – the is no file lock. There is simple cure for this, but far from perfect, and at the cost.

Before we begin

I assume you know what we are talking about, and by miracle you found this SEO un-optimized site and want to know more about this DFS magical trick (which it isn’t).

This article assumes you have DFS Namespace cluster in place with at least two servers and that you have Replication for shared folders in place.

Just to be clear, although Namespaces and Replication are both in DFS Management that doesn’t mean that these services are inseparable. Quite contrary – best to my knowledge these are separate services and processes without any hard connection between them.

Why am I saying this? Because if you modify some Namespace options it won’t affect Replication.

As always – best way to convince yourself is to test things out. Please if you are going to try this, do this in a LAB or test environment, not in production. I could not take responsibility if you break, lose something (even your mind after you realize the damage).

Please, test first.

Is there a way to prevent data loss in files on DFS and two users accessing same file at the same time?

There is no “effective” cure for this problem with DFS, at least if you want your DFS and file shares to be highly available.

If you want load balancing – then this solution will not apply to you.

If you want high availability – also not perfect. But, enough theory, let me show you what I have.

I have two servers (TDFS1 and TDFS2) hosting DFS Namespace on folder named Data1 – this folder is also replicating between these two servers TDFS1<->TDFS2.

If I open my namespace \\TFileServer\TFileServer (I know, I’m not person with best imagination in the world) and right click on Data1 file share and open DFS tab, we can see that the are two referals for this link TDFS1 and TDFS2 – this client is connected to TDFS1. Other one can be connected to TDFS2 and editing the same file. In the end, user who save last – wins – and overwrites other changes.

If I open my DFS Management, under Namespaces I can see my Data1 share and in Folder Targets we can see that both Referral Status on TDFS1 and TDFS2 is Enabled.

Thing is simple – Disable one of the referrals.

Since I showed you that my client is active on TDFS1, I will disable TDFS1 to see what happens.

Ok, TDFS1 is disabled Referral in Namespace is disabled.

Does that mean your replication from TDFS1 to TDFS2 and vice versa is stopped? No

If you open Replication for Data01 you can see that both targets and Connections are enabled.

That’s what I’ve been rambling in the beginning, Namespaces and Replication is not tightly connected, these are separate services.

You can also check simply by creating few files and folders that replication works, despite one Namespace referral is disabled.

I’m back at the Client to see what is going on for our users. One switched to TDFS2 and the one that was actively editing on TDFS1 is still connected on that node. After reboot, the second client also connected to TDFS2

After reboot I can only see TDFS2 as a Referral.

This now means that all of our users will be connecting to TDFS2\Data1 share – and that means no more same files opened at the same time by different users and possible data loss.

What this also means is that there is no load balancing or automatic high availability.

Also, if somebody is accessing on some other way disabled Namespace referral (folder is still shared) you still haven’t gained much.

If you ever need – you can simply enable second referral (TDFS1) and after reboot all clients will see it.

It all depends on your use case if this fits you or not. But this will solve your problem with file conflicts and data loss (caused by different users opening same file)

Replication is going on behind scenes. And if you lose one DFS node (hardware malfunction), you can always just enable second one you disabled and downtime will be minimal.

Testing

Lets test our change. I created simple document in Libre Office on Client1 and left it open.

After that I went to Client2 and tried to open same file

Good. If you test with notepad and simple txt file, you will still be able to overwrite. But Libre or MS Office are doing the work correctly.

File I created is till replicated on both nodes – even to the one that we disabled Namespace for. Perfect

Ok, so the trick works.

Conclusion

This is far from perfect solution, but it is solution which will save you headache of lost files and file changes and it will enable you to have some kind of high availability – because all the changes are replicated on both servers, and if you lose one, you can just enable Namespace referral you disabled and people can keep working.

Again, not ideal, test it out, see if this fits your need, and if it does – great. If not, and you have many problems with DFS conflicts, maybe it is time for some other solution.

Disclaimer