Disk-Disk synctoy overwrites each and every files again RRS feed

  • Question

  • This is a re-post of previous message with additional info.

    Synctoy [used to be version 1.4 now 2.0] is a tool I use regularly. I use it to backup my files
    from a central disk [a Netgear NAS] to machines around the house. I Synctoy'ed this NAS
    disk [z: drive on the left side of the sync] to a USB external local disk [d: drive on the right
    side of the sync] each month as a backup in addition to daily folder-folder backup.

    However, subsequent Synctoy runs [z:\ ---> d:\] of  NAS disk to the USB external local disk
    will take 2-3 days because Synctoy overwrites each and every files [more than 100,000  files
    of various types including pdf, doc, txt, c, pps, jpg, wav, ...] again! The number of modified
    files are less than 100 files each month. It is as if Synctoy sees that all the file attributes
    from the source NAS disk are new or modified or different from the same local USA external disk
    which I use every month. Synctoy is run with the "Contribute" setting.

    Since reading more about posts re. NAS files corruption after Synctoy runs I am a bit concerned
    whether some of my files are not backed up correctly and/or corrupted. Reply to this issue and
    my concern are highly appreciated.

    Michael Wyn
    • Edited by mwyn1 Friday, March 20, 2009 3:21 AM updated
    Thursday, March 19, 2009 3:56 PM


  • Hi -

     While I am not sure about the overwriting that is happening, we are definitely seeing reports of data corruption on NAS drives. So I do recommend that you not use SyncToy 2.0 to back up to these disks. We have identified a fix and it will be fixed in a future release so we hope you will get back to using the next version of SyncToy !

    Deepa ( Microsoft Sync Framework)
    Tuesday, March 24, 2009 11:59 PM

All replies

  • This problem sounds similar to mine.  My primary backup purpose is to keep 2 machines in two cities exactly the same when I commute between them, using a traveling external hard drive.  I've had few problems with this arrangement in the past.

    Last week I upgraded on an XP platform from 1.4 (which I've used for years) to 2.0, without any apparent problems.  It appears that 2.0 works better than 1.4, with more options and fewer minor glitches.  Today I upgraded another machine (Vista this time) to 2.0, and tried to sync from my travel drive.  I followed the directions closely - ran a full synced backup using 1.4 before I converted to 2.0, and then ran another full backup with the new 2.0.  This time, it wanted to overwrite 37,000 files, and it wanted to replace newer files with older ones.

    On close inspection, I found that Version 2.0 was changing the modified date of every file on the Vista drive to exactly 7 hours different from (later than) the correct time on the travel drive.  To work around this, I erased all user files on the Vista C-drive, and copied directly from the travel drive to the empty C-drive, ensuring that I had identical copies.  When I then ran a test sync backup, 2.0 had again changed all the modified dates, and wanted to overwrite everything again.

    No doubt, if I allow this, the next time I try to sync the travel drive to the XP machine, it will then see the newly changed dates and will overwrite again.  And so on and so on.  Apparently I've now completely lost my capacity to sync between the two separate machines.

    I note that I'm the only responder to your post, but surely we aren't the only ones to encounter this problem.  Anybody out there have any ideas?  Or does anyone know of a replacement to SyncToy that works as simply and easily as it used to?  And any opinions on the apparent XP / Vista disparity?

    Any help would be most welcome.

    Sunday, March 22, 2009 1:14 AM
  • Hi GLARCH,

    Thanks for your email. It's interesting that you see the 7-hour discrepancy.
    Is it a [SyncToy 2.0] software bug confused by  GMT and local time on the source and
    destination machines/disks? I have run SyncToy 2.0 from a NAS disk
    [Netgear ReadyNAS NV+] which was configured to be NTFS to FAT-32 XP and
    NTFS Vista-based machines. The overwriting problem exists in both cases.

    What scares me the most is the possibility of corrupted data hidden
    in our back-ed up disks/machines. I am experimenting with another Microsoft
    power toy, Robocopy and the jury is still out on this tool. You may want to try it
    to see if it is more reliable. I'd like to hear more about this issue if you have
    additional info/solution.


    Monday, March 23, 2009 9:21 PM
  • Hi -

     While I am not sure about the overwriting that is happening, we are definitely seeing reports of data corruption on NAS drives. So I do recommend that you not use SyncToy 2.0 to back up to these disks. We have identified a fix and it will be fixed in a future release so we hope you will get back to using the next version of SyncToy !

    Deepa ( Microsoft Sync Framework)
    Tuesday, March 24, 2009 11:59 PM
  • Deepa -

    Do I understand correctly from your sign-off (Microsoft Sync Network) that you work for MS and are part of the SyncToy team?  I appreciate your feedback, and I look forward to acquiring a future release of SyncToy with these problems fixed.  If you work for MS, could you post for download or send by mail a copy of the old SyncToy 1.4?  As it is, all my back-up provisions are shut down on my Vista machines, and I cannot find a workaround.  Version 1.4 worked just fine for years, and I'd like to have it back, at least until future 2.0 releases work properly.  Unfortunately, I never saved out 1.4 before running.  I really liked the way SyncToy worked - intuitive, easy, automatic, and idiot-proof.  And I'd prefer to avoid switching to something like RoboCopy which requires command-line operations and potential lost data through a faulty understanding of the procedures.

    Your comments spoke specifically to problems occurring on NAS drives - I confess that I don't know what a NAS drive is.  As to file structure, all my files and drives are and have always been set up with NTFS structure, if that is an issue.  Your comments, however, did not address the internal re-set of the "modified date" which is causing the continual over-write.  I hope that issue will be dealt with in your upcoming fix.  For what it's worth, the time change on my system is always 7 hours backward (earlier), and SyncToy 2.0 then insists on replacing what it thinks is the later version with the earlier one.  Also, FYI, my systems are in two different time zones (Pacific & Central), with a two-hour difference between my travel destinations.  This has never been a problem with SyncToy 1.4 in the past.

    I hope you can help me revert to 1.4, and I hope that a fixed version of 2.0 is available soon.


    Wednesday, March 25, 2009 2:42 PM
  • Hi All

    I am also getting the same problem, but with a 2 hour difference between the files.  I am using v2.0 and syncing between a laptop and a desktop via USB, as the client site does not allow laptops to connect to their network.  Both machines are configured to be in the same timezone and have "automatically adjust clock for daylight saving changes" checked. Both machines are running Windows XP (desktop has SP2, laptop has SP3).

    The most unusual aspect of the issue is that it is not on every folder pair that I have this problem.

    Any ideas?


    Thursday, April 9, 2009 2:25 AM
  • Hi Deepa:

    I've been using SyncToy 1.4 for 2 or 3 years and it worked great.  I had to recently reload windows on my laptop and upgraded to v2.0.  This version has less features (no more combine, etc.) and percieves a 4-hour difference between thousands of files that I just copied over from my desktop.  I have no doubt that if I assent to the overwriting, it will still want to overwrite them again tomorrow.  There doesn't seem to be any rhyme or reason as to which files have the 4-hour difference as there are plenty that have the correctly corresponding dates and times and don't need overwriting.  This upgrade is a huge disappointment and should either be fixed or removed from your download library.

    I can't even reload v1.4 because it's not compatible with MS .NET framework 2 or 3, both of which are loaded on my machine.

    Tuesday, April 14, 2009 11:36 PM
  • I get the same problem using a Terrastation NAS but with a 1 hour difference on modification times.  When will the release with the fix be available?
    Wednesday, April 22, 2009 3:21 PM
  • I'm a new SyncToy user, and I'm seeing this effect using SyncToy between a computer using NTFS and a commonplace FAT32 USB thumbdrive. I have tried setting it to "Check File Contents" which does not help. It still wants to overwrite all files. (This shortens the life of a flash memory thumbdrive, besides taking a long time.)

    It also appears to get tripped up by different folder creation dates, even if the actual file date stamps are identical. You will have different folder creation dates if you copied the files using something like Windows Explorer. This appears to be another case where it wants to overwrite all files, or mysteriously only most but not all of them.

    The venerable WinDiff did not have these problems, though it is extremely limited compared to SyncToy. But until these issues of overwriting all files are resolved, I really am going to have to continue using windiff, with all its warts and limitations.

    Roger Deschner
    Friday, April 24, 2009 7:47 AM
  • I OFTEN transfer many files twixt several p.c.'s (&/or) USB drvs, as--I do a lot of service/tech work for customers, &  adding new music to my p.c.'s for my DJ srvc.  I too, am experiencing the same/similar issue(s).
       I do NOT require this s/w to over-write EVERYTHING...;  I jus want it to 'synch' the files.  It appears (at-this-point) that, it would be far easier (&, invariably) less time-consuming, to utilize the infamous "NO-to-all" feature for copying files.   Whuut say u???

     Posthumously yours, Keith (errr, 'Bob')
    • Edited by BobAlot Friday, April 24, 2009 7:08 PM
    Friday, April 24, 2009 7:04 PM
  • This time difference bug makes Synctoy 2.0 almost worthless as a synchronization tool, and that's really sad...Synctoy wants to overwrite EVERYTHING once this problem presents itself, completely failing as a syncronization tool.

    It is also unbelievable that this problem has been reported for MONTHS in forums all over the world, including this official Microsoft forum, and no action has been taken to address it. Is giving feedback really worth it in this case...? (until now, the answer seems to be NO).
    Saturday, July 11, 2009 2:56 PM
  • I have had the same issue in rewriting everything and possibly corrupting data- when trying to sync between ntfs and fat32.  I just avoid doing that!!  I am curious- how are the hard drives in your NAS formatted??    i have run across other situations where going from NTFS to FAT32 results in losing information that is not obvious in NTFS - like audio data from movies.  
    Thursday, September 17, 2009 2:53 AM
  • Hi.  I have searched high and low for a solution to this problem.  In my case, it only appeared with Windows 7 and Windows Live Mail.  All .eml files are update on the Windows 7 system every time I bring up Windows Live Mail.

    It means SyncToy wants to overwrite every single .eml file in every run.

    I will try deleting that key.

    Does anyone know of any negative consequences?
    I posted a problem like this in the windows 7 forums - figure it is their bug.

    Thanks all.
    • Proposed as answer by BasementDoc Monday, March 29, 2010 2:49 PM
    Sunday, November 8, 2009 10:26 PM
  • All,


    See version 2.1 where they claim a fix to listed bugs:



    • Proposed as answer by BasementDoc Monday, March 29, 2010 2:49 PM
    Monday, March 29, 2010 2:49 PM
  • Thanks for this.  I saw that note, but my problem - the date change on the .eml files, proved to be from Windows 7 and Windows Live Mail.  Something wierd in the registry keys that appears with Windows Live Mail and Windows 7.  I could copy that here, but it was fixed over there.  You can mark my part of this resolved by that.

    I could no longer find a reference to that problem in the Windows 7 forums.  Interesting.


    Monday, March 29, 2010 10:11 PM