locked
unexpected behavior when renaming files in the target RRS feed

  • Question

  • All,
     
    Forgive me if this has been discussed previously but I was unable to find anything appropriate to my situation.

    Here is my scenario. I am configuring a one-way sync from a remote to a local folder. After the sync has occurred, a second process will rename the files in the local folder. when the sync fires again, not files are copied from the remote to the local folder! I had expected that the files would be copied down again. The Sync framework must be able to determine that the rename occurred in the local folder and the files do not need to be copied down again. Fine. This actually works for me as this is the behavior that I need, but it was still unexpected.

    Now, let's say that I then update the contents of one of the files in the remote folder. When the sync occurs next, the sync framework does copy the new contents down but it renames the file in the local folder back to the original name. This was not even close to what I had expected.

    are the behaviors that I have described, the designed behaviors? If so, is there a way to affect them? Specifically the rename back to the original filename when the content of the remote folder is changed. This is a show-stopper for me.

    TIA

    -Mike
    • Moved by Max Wang_1983 Thursday, April 21, 2011 5:53 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Monday, February 23, 2009 3:20 AM

Answers

  • Hello Mike,

    The behavior is correct. At step 5, because remote files were updated after local files were renamed, when syncing from remote to local, FileSyncProvider will choose last modified writer as the winner and remote changes will override the local changes.

    Files are identified by globally unique identifier, not by file names. Simple rename of a file does not make it a new file. If a rename happens on a remote file and sync happens to a local file, the local file will be renamed as well, and only one file instance will exist on local side.

    Hope this helps,

    Patrick

    Friday, February 27, 2009 6:24 AM

All replies



  • Mike Levy said:

    All,
     
    Forgive me if this has been discussed previously but I was unable to find anything appropriate to my situation.

    Here is my scenario. Could you describe your situation? Which Sync Framework product are you using? i.e. SyncToy / FileSyncProvider I am configuring a one-way sync from a remote to a local folder. After the sync has occurred, a second process will rename the files in the local folder. I assume that you renamed files in remote folder before sync. when the sync fires again, not files are copied from the remote to the local folder! I had expected that the files would be copied down again. The Sync framework must be able to determine that the rename occurred in the local folder and the files do not need to be copied down again. Yes. you are right. unless there are changes on the remote folder, there is no changes that need to be sync'd. In sync concept, destination's knowledge contains the source's knowledge. thus, the same files will not be sent. Fine. This actually works for me as this is the behavior that I need, but it was still unexpected.

    Now, let's say that I then update the contents of one of the files in the remote folder. When the sync occurs next, the sync framework does copy the new contents down but it renames the file in the local folder back to the original name. I am not clear on this one. Did you rename the files in remote folder to original name? What were the operations done on the remote files before the second sync? This was not even close to what I had expected.

    are the behaviors that I have described, the designed behaviors? If so, is there a way to affect them? Specifically the rename back to the original filename when the content of the remote folder is changed. This is a show-stopper for me.

    TIA

    -Mike

    Hello Mike,

    I inlined some answers and questions above.

    Thanks,

    Patrick
    Thursday, February 26, 2009 12:35 AM
  • >> Could you describe your situation? Which Sync Framework product are you using? i.e. SyncToy / FileSyncProvider

    I've duplicated the behavior on both the release and latest CTP.


    >> I assume that you renamed files in remote folder before sync.

    No. I am NOT renaming the files in the remote folder. Only the files in the local folder are being renamed. They are renamed to indicate that they have been processed by a second program.

    >> I am not clear on this one. Did you rename the files in remote folder to original name? What were the operations done on the remote files before the second sync?

    Here is the scenario. For simplicity, let's assume that both the remote and local folders are empty.

    1. Some process places files in the remote folder.
    2. At nexts sync, FileSyncProvider copies the files to the local folder.
    3. Files in the local folder are renamed.
    4. At some point in time one or more of the files in the remote folder are updated by some user or process.
    5. At next sync, FileSyncProvider will renamed the files in the local folder back to their original names and update them with the updates that were made to the remote folder.

    At step 5 (above) I had expected the FileSyncProvider to copy the updated files from the remote to the local folder as new files since the replicates in the local folder had been renamed.

    TIA

    -Mike


    Thursday, February 26, 2009 2:18 PM
  • Hello Mike,

    The behavior is correct. At step 5, because remote files were updated after local files were renamed, when syncing from remote to local, FileSyncProvider will choose last modified writer as the winner and remote changes will override the local changes.

    Files are identified by globally unique identifier, not by file names. Simple rename of a file does not make it a new file. If a rename happens on a remote file and sync happens to a local file, the local file will be renamed as well, and only one file instance will exist on local side.

    Hope this helps,

    Patrick

    Friday, February 27, 2009 6:24 AM