none
Deletes Not Propagating with Michael Clarks's Azure File Sync Provider RRS feed

  • Question

  • Using the code associated with Michael Clark's article on syncing file's with Azure here:  http://blogs.msdn.com/b/sync/archive/2009/12/03/synchronizing-files-to-windows-azure-storage-using-microsoft-sync-framework.aspx I'm not getting the expected behavior when I delete a file on the azure store.  My expectation is that after I do a sync, I can delete a file on either the local file system or the azure container (that is, remove a blob entry, not the container itself) and the delete will be repeated on the other side.  I've made sure to run the sync in both directions.  I'm finding that when I delete the file on the file system, it does get deleted in the azure container, but when I delete it from the azure container, it never gets deleted from the local file system.  I do notice that if I insert to the azure container, that gets propogated, and if I update a blog in the azure container, that gets propogated, but delete's just don't seem to.

    Thanks for contributing this example. It is going a long way in helping me understand the simple sync provider.


    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider
    Thursday, October 21, 2010 1:12 AM

Answers

  • Hi Peter,

    I assume you are asking about what causes delete item on provider to be called. It is called on destination provider when source has deleted the item. During change enumeration (i.e. exposed as EnumerateItems call on source provider), source will skip reporting this item and this will be perceived as a local delete on source provider. Then, during sync, we look at the destination's knowledge and ask whether it is aware of this deletion of the item that happened on source. Then, during sync, orchestrator calls delete the same item on destination provider. This is the DeleteItem method on the provider which the provider writer needs to handle by physically deleting the item.

    Hope this helps,

    Patrick

    • Marked as answer by Peter Kellner Saturday, October 23, 2010 8:15 AM
    Friday, October 22, 2010 8:10 PM

All replies

  • Hi Peter,

     

    I’m going to have to dust that sample off a little to take a look.  I thought I had tested that scenario, not exactly as you describe but rather deleting from the desktop and making sure that would flow both up to the cloud and then down to other desktop replicas.  I’m not sure why what you describe should be any different but maybe there is something that is missing.  Let me take a look at it and get back to you.  Fair warning it might take me a day or two do find some time to dig into this.

     

    Cheers,

    Mike Clark

    Group Manager

    Microsoft Sync Framework

     

    Thursday, October 21, 2010 4:22 AM
    Moderator
  • Turns out you did test the scenario with delete.  I went back and tested your original distirbution and indeed, it did propogate the delete. I've made a bunch of changes (though I thought not to the basics of how it propogates deletes) and my modified version does not propagate delete.  The changes I made are (so I thought) just around how I authenticate. I've changed everything to use signatures rather than passing the azure credentials.  I get the signature from a WCF web service allowing me to make this multi-tenancy and secure.

    So, now my question is, how can I debug this?  What triggers the "DeleteItem" to be called.  I had assumed orcestrator enumerated the source, the enumerated destination and if there was a difference turned around and called delete to reflect the difference.

    Thanks


    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider
    Thursday, October 21, 2010 1:14 PM
  • Hi Peter,

    I assume you are asking about what causes delete item on provider to be called. It is called on destination provider when source has deleted the item. During change enumeration (i.e. exposed as EnumerateItems call on source provider), source will skip reporting this item and this will be perceived as a local delete on source provider. Then, during sync, we look at the destination's knowledge and ask whether it is aware of this deletion of the item that happened on source. Then, during sync, orchestrator calls delete the same item on destination provider. This is the DeleteItem method on the provider which the provider writer needs to handle by physically deleting the item.

    Hope this helps,

    Patrick

    • Marked as answer by Peter Kellner Saturday, October 23, 2010 8:15 AM
    Friday, October 22, 2010 8:10 PM
  • Thanks Patrick,

    This does make sense to me.  The problem I was having was that in the ApplyChanges event, I had mistakenly referenced a null object which was causing the problem.  The strange thing is that my debugger would not stop on the line of code with the illegal null reference.  Is there a setting I can make that will make it stop? I spent a lot of time looking for more complicated problems when it turned out to be simple, but best I can tell, I have no way to know that.  The stack trace does not show me where the error was, it just disappears into a COM object.  Any suggestions on debugging? Is there a log anyplace so at least I know how far things went?

    Thanks,


    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider
    Saturday, October 23, 2010 8:18 AM