Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Sync with SyncDirectionOrder.Download doesn't get a file deleted from the remote provider RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    1
    Sign in to vote

    I'm having a problem with a below scenario when using the AzureBlobSync sample from http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sync&ReleaseId=3638

    The sample basically synchronises files between a local folder and Azure blob container. The only thing I've changed is to add a line which allows me to switch direction of the sync between SyncDirectionOrder.Download and SyncDirectionOrder.Upload

    With that set up I'm following these steps:

    1. Add a file to local folder
    2. Run sync with direction Upload - file get's uploaded to azure container
    3. Delete the file in local folder
    4. Set direction to Download
    5. Run sync - no changes are detected when I'd expect orchestrator to detect that remote provider has a file that doesn't exist in local provider and therefore it should be inserted into local provider

    Am I missing something?

    Regards,

    Piotr

    Thursday, October 28, 2010 3:51 PM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    What you saw is expected behavior. SyncFx depends on sync metadata to track changes in data stores. In your case, the deletion in the local side is the newest change, and there is no change in azure side. Nothing will be synced from Azure to local store since local folder knows every changes of the Azure container.

    If you deleted an item in local folder and want the Azure container to send it back, you need to update same item in Azure contrainer and are expected to resolve a delete-update conflict on the local folder during the download sync with remote win conflict resolution policy.

    Thanks,
    Dong 

    This posting is provided AS IS with no warranties, and confers no rights.
    Thursday, October 28, 2010 6:25 PM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    What you saw is expected behavior. SyncFx depends on sync metadata to track changes in data stores. In your case, the deletion in the local side is the newest change, and there is no change in azure side. Nothing will be synced from Azure to local store since local folder knows every changes of the Azure container.

    If you deleted an item in local folder and want the Azure container to send it back, you need to update same item in Azure contrainer and are expected to resolve a delete-update conflict on the local folder during the download sync with remote win conflict resolution policy.

    Thanks,
    Dong 

    This posting is provided AS IS with no warranties, and confers no rights.
    Thursday, October 28, 2010 6:25 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    Thank you for your answer. It's not what I wanted to hear :) but I was suspecting that this might be the case after all the failed tests I've done.

    I'll try to force azure provider to 'think' the item has been updated to force conflicts, as you suggested, and try to control them with a custom ConflictResolutionPolicy.

    Thanks again,

    Piotr

    Friday, October 29, 2010 9:23 AM