locked
Bi-Directional sync based on the timestamp RRS feed

  • Question

  • Hi,

    I am trying to do a two-way sync on files and folders, based entirely on the timestamp.  In other words, there's no definite "source" and "destination", whichever update/deletion/creation is more recent it will be replicated.

    For example, if FileA.txt is deleted on Server 1 at 1 pm, FileA.txt is updated on Server 2 at 2 pm, then I would like FileA.txt to be copied from Server 2 to Server 1.

    I see that there are two SyncDirectionOrder options that I can use: UploadAndDownload, and DownloadAndUpload.  My understanding is these two options tells Sync Framework whether to sync according to the source or the dest, and is not doing what I want.  Is there any way I can get around it?

    Thank you.

    • Moved by Max Wang_1983 Thursday, April 21, 2011 5:38 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Thursday, March 19, 2009 10:52 PM

Answers

  • Hi there,

    I understand you're talking about the file sync provider.

    "I see that there are two SyncDirectionOrder options that I can use: UploadAndDownload, and DownloadAndUpload.  My understanding is these two options tells Sync Framework whether to sync according to the source or the dest, and is not doing what I want"

    This is not exactly what it is doing. The UploadAndDownload/DownloadAndUpload settings only specify the direction in which changes are sent first. It doesn't imply anything about which changes will be picked up if there's a conflict between changes on two endpoints. Using your example, it just means that either we attempt to send the delete the update first, but *how* they are actually resolved would be the same regardless of the download/upload setting.

    Obviously when there are no conflicting changes FSP does the right thing and makes sure the right changes are synced. It gets a bit more tricky for conflicts. In its V1 release FSP does not allow customizing the conflict resolution policy and uses its own pre-set policy which is:

    - for update/delete conflicts, the update always wins regardless of timestamps. This was chosen to prevent data loss
    - for update/update conflicts, the latest update wins (which is your desired behavior). Again Upload/Download has no effect on that

    Right now it's not really possible to do update/delete with the "last modification wins" resolution, sorry.

    Lukasz
    • Marked as answer by ohanna Tuesday, April 7, 2009 3:47 PM
    Tuesday, March 24, 2009 7:06 PM
  • Hi there,

    The current conflict policies that Lukasz noted come into effect for all sync directions including Upload and Download.

    In V2.0 CTP1, there's no change in conflict policy, but there likely would be a change in a future release. Likely, there would be support so one can specify the conflict policy to the effect that a destination file wins or the source file overwrites the destination file.

    But that still may not solve your "delete - time" issue. MSF does not track delete times - it becomes aware of the file or folder delete only when sync is initiated.

    Sameer

    • Proposed as answer by Sameer[MSFT] Tuesday, April 7, 2009 6:34 AM
    • Marked as answer by ohanna Tuesday, April 7, 2009 3:47 PM
    Tuesday, April 7, 2009 6:34 AM

All replies

  • I think my problem can be resolved by comparing the lastwritetime/creationtime of the currentfiledata and the newfiledata in the ApplyingChange event handler.

    But, my new problem is, I cannot figure out how to determine when a file was deleted.  Is there such a thing as "deletion time" in MS Framework?  If a file is deleted on one server and updated on another, I need to determine which one happens last.

    Thanks for your help.
    Friday, March 20, 2009 6:22 PM
  • Hi there,

    I understand you're talking about the file sync provider.

    "I see that there are two SyncDirectionOrder options that I can use: UploadAndDownload, and DownloadAndUpload.  My understanding is these two options tells Sync Framework whether to sync according to the source or the dest, and is not doing what I want"

    This is not exactly what it is doing. The UploadAndDownload/DownloadAndUpload settings only specify the direction in which changes are sent first. It doesn't imply anything about which changes will be picked up if there's a conflict between changes on two endpoints. Using your example, it just means that either we attempt to send the delete the update first, but *how* they are actually resolved would be the same regardless of the download/upload setting.

    Obviously when there are no conflicting changes FSP does the right thing and makes sure the right changes are synced. It gets a bit more tricky for conflicts. In its V1 release FSP does not allow customizing the conflict resolution policy and uses its own pre-set policy which is:

    - for update/delete conflicts, the update always wins regardless of timestamps. This was chosen to prevent data loss
    - for update/update conflicts, the latest update wins (which is your desired behavior). Again Upload/Download has no effect on that

    Right now it's not really possible to do update/delete with the "last modification wins" resolution, sorry.

    Lukasz
    • Marked as answer by ohanna Tuesday, April 7, 2009 3:47 PM
    Tuesday, March 24, 2009 7:06 PM
  • Thanks a lot for your response Lukeasz.

    I had totally mis-understood what the SyncDirectionOrder means.  Is it true that this conflict policy

    "- for update/delete conflicts, the update always wins regardless of timestamps. This was chosen to prevent data loss
    - for update/update conflicts, the latest update wins (which is your desired behavior). Again Upload/Download has no effect on that"

    only applies to bi-directional updates.  In other words, if I wanted to always sync my destination according to my source (or the other way around), I can use the one directional sync (SyncDirectionOrder.Upload or Download) and the above conflict policy won't come into effect?

    I see that there is a version 2 of the Sync Framework (Microsoft Sync Framework V2.0 CTP1 http://www.microsoft.com/downloads/details.aspx?FamilyId=109DB36E-CDD0-4514-9FB5-B77D9CEA37F6&displaylang=en).  Is there any change on the conflict handling policy in this version?

    Many thanks for your help.

    Wednesday, March 25, 2009 3:40 PM
  • Hi there,

    The current conflict policies that Lukasz noted come into effect for all sync directions including Upload and Download.

    In V2.0 CTP1, there's no change in conflict policy, but there likely would be a change in a future release. Likely, there would be support so one can specify the conflict policy to the effect that a destination file wins or the source file overwrites the destination file.

    But that still may not solve your "delete - time" issue. MSF does not track delete times - it becomes aware of the file or folder delete only when sync is initiated.

    Sameer

    • Proposed as answer by Sameer[MSFT] Tuesday, April 7, 2009 6:34 AM
    • Marked as answer by ohanna Tuesday, April 7, 2009 3:47 PM
    Tuesday, April 7, 2009 6:34 AM
  • Thanks Sameer for the information.

    You are right.  I don't think there's anyway I can solve my "delete - time" issue :(

    -H
    Tuesday, April 7, 2009 3:46 PM