locked
Renames deletes in subfolders not recognised correctly between the FileSyncProvider and FullEnumerationSimpleSyncProvider RRS feed

  • Question

  • I've written a class deriving from the FullEnumerationSimpleSyncProvider and use it for a one-way upload sync from a FileSyncProvider to my custom FullEnumerationSimpleSyncProvider. When I rename a file in the root of my source replica, a call to my UpdateItem() implementation is called and the file is renamed correctly. However, if I rename a file which is in a subfolder of the source replica, it calls the InsertItem() method instead of UpdateItem(). I can only assume that this is due to my EnumerateItems() method not passing the correct data into FullEnumerationContext.ReportItems() method?

    I get the same problem when I delete a subfolder in the source replica, it doesn't call DeleteItem(). It works fine when not in a subfolder though.

    EnumerateItems is returning the full relative path to the files in the destination replica, e.g. "foo\bar.txt".

    What else can I check to fix this problem?
    Tuesday, June 8, 2010 9:58 AM

Answers

  • I think I've found the problem - I was returning inconsistent values for the file "name" in the out ItemFieldDictionary keyAndUpdatedVersion parameter of the InsertItem and other methods. In some places I was using just the file name, and other places used the file name as well as relative path. This seems to have fixed it and makes sense now, it was just hard to track down! I need to confirm this for additional test cases and for deletes but I'm pretty confident it will be fine now.
    Wednesday, June 9, 2010 4:23 PM

All replies

  • You can look into the metadata store on the fileSyncProvider side (a hidden file called metdataFSP.Harmonica) and simpeSyncProvider side. You can copy the FSP metadata store and also simple provider metadata store to a different directory and open with Sqlserver management studio (SSMS)

    Compare the items in both the metadata stores , after the sync, you should see 2 sides have same number of items and with same global item id. You can also look at other defined columns.

    Tuesday, June 8, 2010 11:29 PM
    Answerer
  • Since I struggled to find it, I'm linking to a post where I explain how to find and open the metadata file:
    http://social.microsoft.com/Forums/en-US/syncdevdiscussions/thread/0d61c8e5-4b02-4dde-a181-20a866e4393c

    Wednesday, June 9, 2010 8:25 AM
  • Below is the data stored in the metadata files for both the FileSyncProvider and the SimpleSyncProvider after taking these steps:

    1. Create "a\b.txt"
    2. Synchronise
    3. Rename "a\b.txt" to "a\c.txt"
    4. Synchronise

    FileSyncProvider

    ItemKey GlobalItemId CreationPartner CreationTickCount UpdatePartner UpdateTickCount AsOfLocalTickCount TouchWatermark TombstoneStatus ChangeUnits WinnerItemId LocalId CreationTime LastWriteTime Attributes FileSize FileRelativePath FileHash CustomIndex0
    0 <Binary data> 0 2 0 2 2 11 0 NULL NULL A 1.2921E+17 1.2921E+17 16 0 a NULL <Binary data>
    1 <Binary data> 0 2 0 12 12 12 0 NULL NULL A\C.TXT 1.2921E+17 1.2921E+17 0 0 a\c.txt NULL <Binary data>

    SimpleSyncProvider

    ItemKey GlobalItemId CreationPartner CreationTickCount UpdatePartner UpdateTickCount AsOfLocalTickCount TouchWatermark TombstoneStatus ChangeUnits WinnerItemId GhostStatus DeadItem LastLocalModification CustomField1_2 CustomField2_6 CustomIndex2  
    0 <Binary data> 1 2 0 6 7 6 1 NULL NULL 0 1 6 NULL 0 <Binary data>    
    1 <Binary data> 1 2 0 10 10 8 0 NULL NULL 0 0 10 c.txt -8.5893E+18 <Binary data>    
    2 <Binary data> 0 6 0 6 7 5 0 NULL NULL 0 0 6 a\b.txt 5.2458E+18 <Binary data>    

    My initial thoughts are that CustomField1_2 of the SimpleSyncProvider has an incorrect value of "c.txt" for ItemKey 1.

    I'm not very familiar with the internals of the metadata stores, do you have any suggestions as to what is incorrect?

     

    Wednesday, June 9, 2010 3:19 PM
  • I think I've found the problem - I was returning inconsistent values for the file "name" in the out ItemFieldDictionary keyAndUpdatedVersion parameter of the InsertItem and other methods. In some places I was using just the file name, and other places used the file name as well as relative path. This seems to have fixed it and makes sense now, it was just hard to track down! I need to confirm this for additional test cases and for deletes but I'm pretty confident it will be fine now.
    Wednesday, June 9, 2010 4:23 PM
  • Great you have found the above issue so far. I suspected some issue related to relative path for fullEnumerationProvider side too. Looking at the metadata store will definitely help with the investigation.

    Wednesday, June 9, 2010 4:47 PM
    Answerer