locked
A new file is created instead of the existing one being updated after a synchronization session RRS feed

  • Question

  • I am using SyncOrchestrator Synchronize to sync files on my local provider and remote providers.  Occasionally after a synchronize session, I'd see the resultant file not being updated, but instead a new one with a slightly different file name gets created.  For example, I have "file1.txt" on both my source and destination locations.  I then update "file1.txt" on my source location, and issue a Synchronize() with direction = Upload.  I see that "file1.1.txt"  is created on my destination location, and "file1.txt" on my destination location is unchanged.

    I've double checked that I have full access rights for everyone for this file and its parent directories, no other process is accessing the file, and using the FileSystemWatcher I have confirmed that the change type is a "change" (not create or delete etc.).

    Note that this only happens occasionally even to the same file.  Could anyone please suggest what might have caused the inconsistency please?  Thank you.

    I am using Visual studio 2005, C#, SyncFramework version 1.

    Code snippet:

            FileSyncOptions options = FileSyncOptions.None;
            FileSyncScopeFilter srcFilter = new FileSyncScopeFilter();
            FileSyncScopeFilter destFilter = new FileSyncScopeFilter();

            //Source Provider
            srcFilter.FileNameExcludes.Add(m_idFileName + ".ID");      
            srcFilter.FileNameExcludes.Add(m_idFileName + ".metadata");

            sourceProvider = new FileSyncProvider(sourceId, sSrcLocation, srcFilter, options);
            sourceProvider.ApplyingChange += new EventHandler<ApplyingChangeEventArgs>(sourceProvider_ApplyingChange);
            sourceProvider.AppliedChange += new EventHandler<AppliedChangeEventArgs>(sourceProvider_AppliedChange);
            sourceProvider.SkippedChange += new EventHandler<SkippedChangeEventArgs>(sourceProvider_SkippedChange);
            sourceProvider.Configuration.ConflictResolutionPolicy = ConflictResolutionPolicy.ApplicationDefined;
            sourceProvider.PreviewMode = false;

            SyncCallbacks scbSrc = sourceProvider.DestinationCallbacks;
            scbSrc.ItemConflicting += new EventHandler<ItemConflictingEventArgs>(OnItemConflicting);

            //Destination Provider
            destFilter.FileNameExcludes.Add(m_idFileName + ".ID");      
            destFilter.FileNameExcludes.Add(m_idFileName + ".metadata");

            destProvider = new FileSyncProvider(destId, sDestLocation, destFilter, options);
            destProvider.ApplyingChange += new EventHandler<ApplyingChangeEventArgs>(destProvider_ApplyingChange);
            destProvider.AppliedChange += new EventHandler<AppliedChangeEventArgs>(destProvider_AppliedChange);
            destProvider.SkippedChange += new EventHandler<SkippedChangeEventArgs>(destProvider_SkippedChange);
            destProvider.Configuration.ConflictResolutionPolicy = ConflictResolutionPolicy.ApplicationDefined;
            destProvider.PreviewMode = false;

            SyncCallbacks scbDest = destProvider.DestinationCallbacks;
            scbDest.ItemConflicting += new EventHandler<ItemConflictingEventArgs>(OnItemConflicting);

            //Set up Synchronization agent which initiates and controls synchronization sessions
            SyncOrchestrator agent = new SyncOrchestrator();
            agent.LocalProvider = sourceProvider;
            agent.RemoteProvider = destProvider;
            agent.Direction = SyncDir;

            agent.Synchronize();

    • Moved by Max Wang_1983 Thursday, April 21, 2011 5:23 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Tuesday, May 5, 2009 10:54 PM

Answers

  • Hi -

    If you do find the circumstances under which this happen please do post back and let us know.

    Deepa
    Deepa ( Microsoft Sync Framework)
    Friday, May 15, 2009 4:20 AM
    Answerer

All replies

  • Hi -
    Some points about your code - you do not need to define a source and destination filter seperately. In fact for the File Sync Provider we require that the filters be identical so that you do not have some files in scope on one side and not in others so it is less error prone to just define one filter). I think I know what your ".ID" file above is ( storing the replica id ) but what is your ".metadata" file contain?

    The behaviour you are defining kicks in only if we think that there are two different files and we should keep them both. More precisely if we think that a rename or a move resulted in two different files having the same name on either side of the synchronize. Any reason that you can think of that your scenario would look like this? Or do you synchronize these folders also in some other relationship or do they always only sync with each other? What direction are they normally syncing in ?

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Wednesday, May 6, 2009 1:13 AM
    Answerer
  • Thanks Deepa.

    What you described does not apply to my case so I've changed my code to use the same filter for both providers, but my problem (generating a file1.1.txt instead of updating file1.txt on the destination) still occurs from time to time.

    The sync direction is always uni-directional (Upload or Download).  When I need to sync in both directions I would call the Synchronize function of the Sync Orchestrator with Upload first and then Download because the bi-directional (UploadAndDownload and DownloadAndUpload) doesn't seem to work for me.

    The .metadata file is generated by MS Sync Framework automatically, and I don't know what it contains.
    Thursday, May 7, 2009 1:04 AM
  • Hi -

    You should be able to skip the ".metadata" file in the filter. We do this automatically and skip the file.

    What are the type of the files that are exhibiting this behaviour?

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Thursday, May 7, 2009 6:08 AM
    Answerer
  • Thanks for your suggestion Deepa. 

    I have only been synching .txt and .doc files so and therefore have only noticed the behavior on these types of files.  Thanks.
    Thursday, May 7, 2009 3:39 PM
  • Hi, is there any more suggestion you could offer me?  Thanks.
    Wednesday, May 13, 2009 7:38 PM
  • Hi -

    I have been looking through our code as well looking if there is any reason that this kind of behaviour would be exhibited in any scenario other than a move/rename on one of the sides. On the other side it would have to be a new file or a file suddenly moving into scope that results in a namespace collision when sync'ing.  But I could not find any clues as to why on normal updates you would see this behaviour - sorry :(

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Thursday, May 14, 2009 5:49 PM
    Answerer
  • I see.  Thanks Deepa.
    Thursday, May 14, 2009 8:31 PM
  • Hi -

    If you do find the circumstances under which this happen please do post back and let us know.

    Deepa
    Deepa ( Microsoft Sync Framework)
    Friday, May 15, 2009 4:20 AM
    Answerer