locked
Problem with synching twice RRS feed

  • Question

  • Hi,

    a new problem, I don't know if i understand it right or it's really a prob...

    when i synch two directorys with direction.download and options: RecycleDeletedFiles | RecyclePreviousFileOnUpdates, the first time everything is allright, but when i delete a file in the destination directory and synch twice no new file is copied, why? i store the syncid in an extra file and befor i sync i read in the syncid, so that i use metadata...

    thx

    greetz bAsTi
    Monday, June 30, 2008 10:04 AM

Answers

  • Yes, the idea of syncing is to bring all end points into convergence. However, you will have to sync back as well, to bring changes from B into A.

     

    The file is not really missing - it has been deleted. To be precise, it has become a tombstone. The metadata for that file still exists, the metadata says that the file has been deleted - so the metadata lives on while the data is gone.

     

    When you sync again from A to B, the sync engine asks A - "was there any other update to file F1 since I last got changes from you?" And the answer is "No", because A has no other changes to report about F1 since the first sync.

     

    However, if you were to sync back from B to A, the engine will ask B - "is there any change A doesn't know about?", and B will say, "yes, I updated F1 (this update happens to be a delete) - can you propagate this to A? The engine will then ask A to delete F1, which will result in F1 becoming a tombstone on A as well.

     

    Now do you want to overwrite deletes everytime, or do you just want to not propagate deletes? The latter is a straightforward to do, for the former I would have to think about how to do it with they sync engine, but the most straightforward way would just be to xcopy from A to B.
    Tuesday, July 1, 2008 7:30 PM
    Moderator

All replies

  •  

    To make sure I clearly understand your scenario:

     

    1. you sync from A to B (B is the destination)

    2. don't make any changes in A but delete F1 in B

    3. sync from A to B again

     

    In this case you will not have any changes, but when you sync back from B to A, F1 should get deleted on A (and moved to the recycle bin).

     

    So it does look like what you see is expected, unless I misunderstood your scenario.

    Monday, June 30, 2008 5:13 PM
    Moderator
  • Ok, you understand my scenario, but I understand under Synching, when in the Destination (B) a file is missing and I sync the next time the file will be recopied. And closely this doesn't function. The idea of synching is just to bring 2 destination to a common denominator, or not?

    Can I build my scenario
    anyway with the options, or anyway different?
    Tuesday, July 1, 2008 7:35 AM
  • Yes, the idea of syncing is to bring all end points into convergence. However, you will have to sync back as well, to bring changes from B into A.

     

    The file is not really missing - it has been deleted. To be precise, it has become a tombstone. The metadata for that file still exists, the metadata says that the file has been deleted - so the metadata lives on while the data is gone.

     

    When you sync again from A to B, the sync engine asks A - "was there any other update to file F1 since I last got changes from you?" And the answer is "No", because A has no other changes to report about F1 since the first sync.

     

    However, if you were to sync back from B to A, the engine will ask B - "is there any change A doesn't know about?", and B will say, "yes, I updated F1 (this update happens to be a delete) - can you propagate this to A? The engine will then ask A to delete F1, which will result in F1 becoming a tombstone on A as well.

     

    Now do you want to overwrite deletes everytime, or do you just want to not propagate deletes? The latter is a straightforward to do, for the former I would have to think about how to do it with they sync engine, but the most straightforward way would just be to xcopy from A to B.
    Tuesday, July 1, 2008 7:30 PM
    Moderator
  • Ok,

    then I
    summarize, that I understand it wrong and it works perfect.
    thx Sid!

    greetz bAsTi
    Wednesday, July 2, 2008 3:15 PM