locked
Does FileSyncProvider lock files while synchronizing? RRS feed

  • Question

  • Does FileSyncProvider lock files while synchronizing?

    It appears that the FileSyncProvider and/or the SynchOrchestrator exclusively locks files while it is copying them.

    For instance, I have two synchOrchestrators running at the same time.

    SyncOrch1 uses two FileSyncProviders; one points to directory A the other points to directory B.  A is the remote directory (ie directory on a file server).

    SyncOrch2 uses two FileSyncProviders; one points to directory A the other points to directory C.  A is the remote directory (ie directory on a file server).

    Both directories B and C are local directories (like c:\temp\dirB and c:\temp\dirC).

    I execute SyncOrch1.Synchronize() and SyncOrch2.Synchronize() in separate threads at virtually the same time.

    During the first pass (when the local directories are empty and no metadata has been created), the results of the Synchronize() function always have several Failures in the DownloadChangesFailed field.  The second pass results are usually 100% good.

    If I run the Synchronize() processes separately (ie one at a time), the results are always 100% good, NO DownloadChangesFailed.

     

    It appears that the FileSyncProvider and/or the SynchOrchestrator has an exclusive lock on the file it is copying.  Can anyone confirm this? or provide an explanation?

     

    Thanks
    Jim

    Monday, November 22, 2010 6:01 PM

Answers

  • The FileSyncProvider will lock the folder while enumerating changes to send over.  The DownloadChangesFailed you are seeing probably occurred because the provider for A was trying to enumerate changes to send to B and C at the same time.

    To prevent this from happening avoid concurrent execution of SyncOrch1.Synchronize() and SyncOrch2.Synchronize().

     


    Maria del Mar Alvarez Rohena Microsoft Sync Framework
    Monday, November 22, 2010 11:19 PM

All replies

  • The FileSyncProvider will lock the folder while enumerating changes to send over.  The DownloadChangesFailed you are seeing probably occurred because the provider for A was trying to enumerate changes to send to B and C at the same time.

    To prevent this from happening avoid concurrent execution of SyncOrch1.Synchronize() and SyncOrch2.Synchronize().

     


    Maria del Mar Alvarez Rohena Microsoft Sync Framework
    Monday, November 22, 2010 11:19 PM
  • If you cannot synchronize your threads, you can reissue the Synchronize that had failed DownloadChanges and the FileSyncProvider will re-enumerate the changes it could not send the last time around.
    Maria del Mar Alvarez Rohena Microsoft Sync Framework
    Monday, November 22, 2010 11:24 PM
  • Thank you for your help. 

    I was trying to simulate what would happen if two computers were trying to synchronize to the same file server at the same time.  I'm sure this will not be a reoccurring problem.  However, it is nice to know what will happen and why it happens.

    Monday, November 22, 2010 11:58 PM
  • Jim,

    In your topology, can B and C folders be eventually on different machines ? It seems your final scenario is to keep two folders (B and C) in sync via a common folder (A) that's reachable to both B and C (while B and C are not reachable to each other).

    If that is so, as Maria suggested, avoid concurrent Synchronize() from multiple orchestrators. If you cannot control when the other thread issues a Synchronize, you could time the threads so they don't synchronize at the same time.

    And in case you cannot avoid concurrent execution across threads, FSP would re-enumerate changes it could not apply due to failing to read the change from the source. So if you issue another sync, it should download the changes again.

    Hope this helps,

    Sameer

     

    Tuesday, November 23, 2010 12:20 AM
  • Sameer,

    Thank you for your reply.  Indeed, they can and will be on different machines. 

    I am mostly concerned with executing two synchOrchestrators on two separate computers running at the same time.  My first test case was to run them on the same computer in separate threads.  I was trying to simulate what would happen and determine the problems, errors, and consequences of this action.

    I have already implemented a solution similar to what Maria suggested.  In fact I have tried catching the following callbacks to see if I could circumvent or even log the problem. (DestinationCallbacks.ItemConflicting, DestinationCallbacks.ItemChangeSkipped, DestinationCallbacks.ItemConstraint).  None of these callbacks are raised at any time during my testing.  Therefore, my only option is to reissue the synchronize() method.  As I stated in my initial post, reissuing the synchronize() method has been working 100% of the time.

    Maria's comment "The FileSyncProvider will lock the folder while enumerating changes to send over." answered my question.

    The only way I can see this being fixed (the right way) is to allow the FileSyncProvider to lock the folder for "read-only".  I don't know any way of controlling that behavior and there is most likely not a way to control that behavior outside of the source code.  If anyone knows of a way, I would be happy to test the theory.

     

    Thanks
    Jim

    Tuesday, November 23, 2010 1:42 AM