![]() This has admittedly caused some performance problems for us, but it's something that we've just learned to deal with (along with trying to throw more bandwidth at the system.) Most of the time, users work on files that are located at their own sites, but for "cross-site" work, they need to open the files over a WAN link, which is much slower. We have site-specific folders for each site. ![]() In our situation, we do use DFS-R, but generally only use it to bring files back to our main site for backup purposes. (Also note that DFS-R cannot replicate files until they are closed.) The next time DFS-R replicates, the version of the file from Site B will overwrite the version of the file at Site A, thereby overwriting the changes made by the user at Site A. The user at Site B also makes changes to the file, but saves and closes the file ten minutes after the user at Site A did so. The user at Site A makes some changes to the file, then saves and closes the file. If my understanding of what you're trying to achieve is accurate, I don't think that DFS-R is going to be an acceptable solution for you, because DFS-R works on a "last writer wins" basis.Īssume that a user at Site A has a file open from that site's server, while at the same time a user at Site B has the same file open from that site's server. ![]() I'm a bit familiar with this, because I work for an engineering firm that also does CAD work and has offices in separate geographical locations, and we've wrestled with the same issue. If I'm understanding you correctly, you would like the files on both servers to remain perfectly in sync, but with the files able to be edited at the same time on either server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |