locked
FileSyncProvider throws ArgumentOutOfRangeException in case of local delete remote update conflict RRS feed

  • Question

  • I'm developing a matching FileSyncProvider (FullEnumeration Simple Custom Provider) to allow for file sync over WCF

    However, the FileSyncProvider throws an ArgumentOutOfRangeException in case of local delete / remote update conflict. Local store managed by FSP, remote store managed by our custom provider.

    The exception is caused by passing null for "pRemoteConflictingItemData" parameter of this method

     

    Microsoft.Synchronization.SimpleProviders._SimpleSyncProviderProxy.OnConcurrencyConflict(CONCURRENCY_CONFLICT_TYPE cctConflictType, IntPtr pLocalConflictingItem, IntPtr pChangeUnitsInConflict, Object pRemoteConflictingItemData, SYNC_RESOLVE_ACTION& pSyncResolveAction, Int32& pfForwardToApplication)
    

     

    I think this parameter is passed from the unmanaged FileSyncProvider so I think it's bug in it, but not sure.

    The exception stack trance is follow

       at Microsoft.Synchronization.Files.FileDataRetrieverAdapter.ConvertUnmanagedToManagedData(Object unmanagedData)
       at Microsoft.Synchronization.SimpleProviders._SimpleSyncProviderProxy.OnConcurrencyConflict(CONCURRENCY_CONFLICT_TYPE cctConflictType, IntPtr pLocalConflictingItem, IntPtr pChangeUnitsInConflict, Object pRemoteConflictingItemData, SYNC_RESOLVE_ACTION& pSyncResolveAction, Int32& pfForwardToApplication)
       at Microsoft.Synchronization.CoreInterop.ISyncSession.Start(CONFLICT_RESOLUTION_POLICY resolutionPolicy, _SYNC_SESSION_STATISTICS& pSyncSessionStatistics)
       at Microsoft.Synchronization.KnowledgeSyncOrchestrator.DoOneWaySyncHelper(SyncIdFormatGroup sourceIdFormats, SyncIdFormatGroup destinationIdFormats, KnowledgeSyncProviderConfiguration destinationConfiguration, SyncCallbacks DestinationCallbacks, ISyncProvider sourceProxy, ISyncProvider destinationProxy, ChangeDataAdapter callbackChangeDataAdapter, SyncDataConverter conflictDataConverter, Int32& changesApplied, Int32& changesFailed)
       at Microsoft.Synchronization.KnowledgeSyncOrchestrator.DoOneWayKnowledgeSync(SyncDataConverter sourceConverter, SyncDataConverter destinationConverter, SyncProvider sourceProvider, SyncProvider destinationProvider, Int32& changesApplied, Int32& changesFailed)
       at Microsoft.Synchronization.KnowledgeSyncOrchestrator.Synchronize()
       at Microsoft.Synchronization.SyncOrchestrator.Synchronize()
       at MySimpleSyncFileProvider.MyTestProgram.DoBidirectionalSync(String pathA, Guid replicaA, String pathB, Guid replicaB) in D:\Sample Code\FSPWithCustomProviderSync\MyTestProgram\MyTestProgram.cs:line 120
       at MySimpleSyncFileProvider.MyTestProgram.Main(String[] args) in D:\Sample Code\FSPWithCustomProviderSync\MyTestProgram\MyTestProgram.cs:line 32
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

    After inspecting my custom provider, I'm sure it's enumerating items and reporting it to the sync orchestrator correctly. To further eliminate the possibility that it's something wrong w/ my custom prover, I've simulated the same scenario using FSPWithCustomProviderSync sample project and got the same exception and the same stack trace

    I'm really appreciating any help regarding this (especially from the MSF team)

    Thursday, July 8, 2010 4:01 PM

Answers

  • Hi Sameh,

    This does appear to be an unfortunate bug. 

    One limited workaround would be to set a resolution policy instead of using custom resolution. 

    Otherwise I think you'd have to implement the native and managed filedataretrievers and the conversion (dataadapter) between the two.  This is not particularily hard, but still annoying.  Let me know if you want more details on this.

    Sorry about this,  I will file a bug for the next release.

    -Jesse

    Monday, August 23, 2010 10:10 PM

All replies

  • Hi Sameh,

    This does appear to be an unfortunate bug. 

    One limited workaround would be to set a resolution policy instead of using custom resolution. 

    Otherwise I think you'd have to implement the native and managed filedataretrievers and the conversion (dataadapter) between the two.  This is not particularily hard, but still annoying.  Let me know if you want more details on this.

    Sorry about this,  I will file a bug for the next release.

    -Jesse

    Monday, August 23, 2010 10:10 PM
  • Actually thinking further about option 2 above, I no longer think it is doable, the FSP does not have the right extension points. 
    Monday, August 23, 2010 11:30 PM
  • Hi Jesse,

    Really thanks for the reply. I'll check the workaround and get a response back here, so other can benefit from it.

    You are right regarding FSP, it almost has no extension points. I've checked it thoroughly before.

    Tuesday, August 24, 2010 9:12 AM
  • Hi Jesse,

    The first workaround works in Upload and Download directions. Although it's a pain to define one conflict resolution policy for all cases, however, it can be treated w/ a little more checks until you get it fixed in next release.

    Also note that it still throw the same exception for UploadAndDownload and DownloadAndUpload sync directions.

    Thanks for help :)

     

    Monday, September 6, 2010 6:19 PM
  • Is there a public page where we can track this bug?
    Monday, October 25, 2010 4:07 PM
  • I have run into this very same bug...was this ever resolved?  

    I do have to able to define a custom policy to allow me to keep both versions of a file in case of a update update concurrency conflict.

    Sunday, January 6, 2013 8:55 AM
  • According the the proposed workaorund for the bug above, i have removed the conflict resolution policy as being ApplicationDefined.  Is there a way that i can still detect an update-update conflict ( mabye in InsertItem  or ApplyingChange  events ) to ensure that both the versions of the conflict are kept?  I almost have my solution  working ...except for the bug specified in the thread above, which causes my sync to crash!!!

    What is bizarre to me is that microsoft has not fixed this bug  in 3 years!!  Arent other people running into this?  Also astonished at lack of support for the sync framework..in documentation and on this forum!!

    Thursday, January 10, 2013 10:56 PM