locked
How low level is SyncToy? RRS feed

  • Question

  • I am looking at using SyncToy 2.1 over a very low bandwidth connection.  The question is this: if i change one byte of a huge file, does SyncToy just change the byte over the connection, or does it copy the whole file?
    My gut tells me that because it is not a constantly running service on both ends, it would have to compare the entire files to get that kind of granularity.  To compare the files would require one to be sent - defeating the purpose.
    Friday, December 4, 2009 12:55 AM

Answers

  • Hi Andrew,
    In short, current SyncToy do not support byte level granularity of file content. SyncToy saves your bandwidth by avoiding copying files which have already been synced (while xcopy and robocopy copy every file).

    For details:
    SyncToy is based on “Sync Framework file synchronization provider”, it detects folder changes as described in http://msdn.microsoft.com/en-us/library/bb902836(SQL.105).aspx. The document shows it does not have build-in support on detecting which byte has been changed (But file synchronization provider leaves places for developers to add such features conveniently for their own applications). SyncToy uses the build-in detecting mechanism and will copy the entire file once it detected that the file content had been changed. This mechanism simplifies the work logic. And besides, comparing 2 files byte by byte before copying in fact does not save any bandwidth, because the comparing work still require transferring file content from one site to another.

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yunwen Bai Friday, December 4, 2009 7:01 PM
    Friday, December 4, 2009 9:50 AM

All replies

  • Hi Andrew,
    In short, current SyncToy do not support byte level granularity of file content. SyncToy saves your bandwidth by avoiding copying files which have already been synced (while xcopy and robocopy copy every file).

    For details:
    SyncToy is based on “Sync Framework file synchronization provider”, it detects folder changes as described in http://msdn.microsoft.com/en-us/library/bb902836(SQL.105).aspx. The document shows it does not have build-in support on detecting which byte has been changed (But file synchronization provider leaves places for developers to add such features conveniently for their own applications). SyncToy uses the build-in detecting mechanism and will copy the entire file once it detected that the file content had been changed. This mechanism simplifies the work logic. And besides, comparing 2 files byte by byte before copying in fact does not save any bandwidth, because the comparing work still require transferring file content from one site to another.

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yunwen Bai Friday, December 4, 2009 7:01 PM
    Friday, December 4, 2009 9:50 AM
  • About bandwidth, there is a function called Distributed File System Replication (DFSR) provided by Windows Server since Windows Server 2003. I heard this tech because another SyncToy user is trying to sync normal folder with a DFS share and met problems. DFSR saves bandwidth not only by avoiding re-copy synced files, but also with diff and compress techniques.

    DFSR function, however, has its own issue for a simple sync task while saving as much bandwidth as possible. It is provided by Windows Sever only (I guess that is why that user is try to sync his local folder with a DFS share). It has no GUI at all, and you need to be familiar with Active Directory and WMI scripting. And although saving bandwidth, the diff work and (un)compress processes spend additional time in each sync site of DFSR.

    So you need to keep the balance and select a solution that mostly fits you. I am investigating DFSR, and I also hope SyncToy can appropriately introduce some advantages from DFSR in the next version.

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, December 7, 2009 10:31 AM