Question about DFS and file locks

Hi,

First, the scenario.  I want to use DFS to enable employees in two different sites to share the same files while each accessing a copy that is local (not across the WAN) to them.  As I understand it, that's a good thing for DFS to be doing.  My question is, however, how does DFS handle file locks?  For example:

1. User in Site A opens file X (from his server A's DFS link copy) and makes some edits and sits in the file from 11am to 2 pm while at lunch
2. At 1pm User in Site B opens the same file X through DFS (but using server B's copy).  Does this user get a "File is in use" warning???  That's the crux of the issue...
3. Is there a way to shorten the default sync of DFS (which I believe is 15 minutes).  When the remote office edits the file on the remote server, we would like to not have to wait 15 minutes to see the changes (assume that our WAN can handle the replication traffic)
4. On machine is Win2003 R2 the other is just Win2003 - I assume I should set up the root on the 2003R2 machine since it has RDC (remote differential compression) which enables only the incremental changes to be be synched.  Or do both machines have to be 2003 R2 for that to work?

If anyone has a better thought on how to keep two remote sites in sync and handle concurrent editing issues (short of sharepoint, of course - too expensive), I'm all ears.

Thanks
goalie1Asked:
Who is Participating?
 
NJComputerNetworksConnect With a Mentor Commented:
DFS with replication is great for READ only data or data that ONLY one person at a time will have access to (for example, home directories.)

DFS with replication will cause problems if multiple users have the ability to modify the same file from multiple locations.  The end result is LAST WRITE WINS..  A guy in North Carolina modifies then saves the FILEX.doc word document at 10:00am.  While a GUY in New JErsey modifies this file at 10:01am...  The result is all the changes made by New JErsey guy is saved....  At least this is how it worked before Windows 2003 R2.

Now, I understand that Windows 2003 R2 can replicate DELTA changes... So, there is a possibility that the whole file will not get modifed...just the piece of the file will get modified. You will have to test this as I can not...  But even if this is true, it userA and userB both try to change the TITLE of the document, the last write will win.

-later
0
 
NJComputerNetworksCommented:
1. User in Site A opens file X (from his server A's DFS link copy) and makes some edits and sits in the file from 11am to 2 pm while at lunch
2. At 1pm User in Site B opens the same file X through DFS (but using server B's copy).  Does this user get a "File is in use" warning???  That's the crux of the issue...  (No the user will NOT get a file lock...there is no file locking using DFS...unless two people try to open the same file on the same server...  )
3. Is there a way to shorten the default sync of DFS (which I believe is 15 minutes).  When the remote office edits the file on the remote server, we would like to not have to wait 15 minutes to see the changes (assume that our WAN can handle the replication traffic)  (Yes, in Windows 2003 R2, you can customize the replication of DFS...)
4. On machine is Win2003 R2 the other is just Win2003 - I assume I should set up the root on the 2003R2 machine since it has RDC (remote differential compression) which enables only the incremental changes to be be synched.  Or do both machines have to be 2003 R2 for that to work?  (It would be recommended to upgrade both machines to Windows 2003 R2....to use delta replication and because Windows 2003 R2 has much improved DFS replication)
0
 
dbarchiesiCommented:
DFS lacks a central feature important for a collaborative environment where inter-office file servers are mirrored and data is shared: File Locking. Without integrated file locking, using DFS to mirror file servers exposes live documents to version conflicts. That is, a colleague in Office A can open and edit a document at the same time a colleague in Office B is working on the same document. In such a scenario, DFS will only save the changes made by the person closing the file last.

The surest and simplest way of eliminating version conflicts when using DFS is to add a true file locking solution - one that offers, at a minimum, real-time detection of file use and immediate remote locking. Such as Peerlock. This assures that when a file is open at location A, all other versions - say local copies at various branch offices - are locked down, preventing anyone from opening and revising it. When the file closes, the file lock is immediately released and ready for synchronization.

PeerLock Software adds file locking to your DFS environment eliminating Version Conflict.
Below is the link to this solution:
http://dfsfilelocking.com

While many customers enjoy the benefits of adding file locking to DFS, please bear in mind the potential synchronization backlogs while using DFS.

For a true solution that offers both real-time file locking AND real-time replication, thus eliminating version conflict and providing a fail-safe collaborative framework, evaluate our complete PEER Collaboration Package.

PeerSync Collaboration is a Full File Collaboration solution including Real-Time file Synchronization and Real-Time File Locking.
For more info go to: http://www.peersoftware.com/solutions/high_availability/server_collaboration_for_file_systems.aspx
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.