Answered by:
Bi-directional FileSync but only delete files if they were deleted on the remote media

Question
-
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
-
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- Proposed as answer by María del Mar Alvarez Rohena Wednesday, February 2, 2011 8:27 PM
- Marked as answer by jim.software Friday, March 4, 2011 10:24 PM
Wednesday, February 2, 2011 8:27 PM -
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
-
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- Proposed as answer by María del Mar Alvarez Rohena Wednesday, February 2, 2011 8:27 PM
- Marked as answer by jim.software Friday, March 4, 2011 10:24 PM
Wednesday, February 2, 2011 8:27 PM -
Thank you Maria! I'll try it and let you know how it worked.Wednesday, February 2, 2011 9:40 PM
-
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