Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Bi-directional FileSync but only delete files if they were deleted on the remote media RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a bi-directional File Synchronizer using FileSyncProvider and SyncOrchestrator. I would like to apply all the normal synchronization options except the delete file. The ideal situation would be, if the file was deleted from the RemoteProvider, it would be deleted on the LocalProvider; but, if the file was deleted on the LocalProvider it would be copied back using the file from the RemoteProvider. The RemoteProvider would be like a master copy that does not allow files to be deleted from.

    Here is a simple illustrated concept model: (file4, file5, and file6 are the primary examples)

    RemoteProvider            LocalProvider   assumptions
file1   --- update local ---->  file1       file1 on remote is newer
file2  <--- update remote ---   file2       file2 on local is newer
file3   --- copy to local --->           file3 is missing from local
file4   --- copy to local --->           file4 was deleted from local
     <--- copy to remote ---   file5       file5 was added to local
_del_   --- delete local ---->  file6(delete)   file6 was deleted from remote


    Wednesday, February 2, 2011 4:57 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    You can achieve this by adding the AppliedChange  event handler to your RemoteProvider, and when you see a change with args.ChangeType == ChangeType.Delete, programatically restore the file args.OldFilePath  from the Recycle Bin.  This then will trigger a file create in the consecutive sync to the LocalProvider.  

     

    Maria del Mar Alvarez Rohena Microsoft Sync Framework
    Wednesday, February 2, 2011 8:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Maria, thank you for your help.  It was what I needed to develop a work-a-round for the shortcomings of the FileSyncProvider and SyncOrchestrator.

     

    I could not use your solution because I do not have access to the Recycle Bin on the Remote computer.

    I used the ApplyingChange Event handler and set the args.SkipChange to True when args.ChangeType == ChangeType.Delete.

    This has one major side effect: The files that were deleted in the local directory will never be copied back (long story about Metadata... i.e. "shortcoming")

    Therefore, after detecting a skipped delete, I delete the Metadata after the synchronize finishes and immediately start another synchronize.  It's a nasty work-a-round to a problem that should be handled in the Provider or Orchestrator.

     

    What are the chances of getting the source code to the MS SyncFramework?  How about open-sourcing it?

     

    Thanks again Maria!  You got me on the right track and I give you credit for that.

    • Marked as answer by jim.software Friday, March 4, 2011 10:24 PM
    Friday, March 4, 2011 10:24 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    You can achieve this by adding the AppliedChange  event handler to your RemoteProvider, and when you see a change with args.ChangeType == ChangeType.Delete, programatically restore the file args.OldFilePath  from the Recycle Bin.  This then will trigger a file create in the consecutive sync to the LocalProvider.  

     

    Maria del Mar Alvarez Rohena Microsoft Sync Framework
    Wednesday, February 2, 2011 8:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thank you Maria! I'll try it and let you know how it worked.
    Wednesday, February 2, 2011 9:40 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Maria, thank you for your help.  It was what I needed to develop a work-a-round for the shortcomings of the FileSyncProvider and SyncOrchestrator.

     

    I could not use your solution because I do not have access to the Recycle Bin on the Remote computer.

    I used the ApplyingChange Event handler and set the args.SkipChange to True when args.ChangeType == ChangeType.Delete.

    This has one major side effect: The files that were deleted in the local directory will never be copied back (long story about Metadata... i.e. "shortcoming")

    Therefore, after detecting a skipped delete, I delete the Metadata after the synchronize finishes and immediately start another synchronize.  It's a nasty work-a-round to a problem that should be handled in the Provider or Orchestrator.

     

    What are the chances of getting the source code to the MS SyncFramework?  How about open-sourcing it?

     

    Thanks again Maria!  You got me on the right track and I give you credit for that.

    • Marked as answer by jim.software Friday, March 4, 2011 10:24 PM
    Friday, March 4, 2011 10:24 PM