none
SyncToy 2.0 not recognizing changes RRS feed

  • Question

  • I've used SyncToy for quite a while between 2 XP Pro computers with no problems. I recently added a Win 7 Pro x64 laptop.  The first sync (from XP to Win 7) went fine.  However, I then added some files to the XP computer and ran SyncToy.  The Preview screen showed that SyncToy wanted to delete all (or at least a lot; I didn't count them) of the files/folders on the XP box. Naturally, I didn't let this Run, but instead changed the option from "Synchronize" to "Echo" and this time Preview showed what I wanted: all the newly added files were set to be copied. I Ran this and the files were copied.

    I changed the option back to "Synchronize" and Preview again showed that the XP files were to be deleted. I changed again to "Echo" and Preview wanted to copy the files over again as if they had not been copied.

    It seems as if a SyncToy index somewhere is not being copied properly or is corrupt.  Is this a permissions issue on the Win 7 box?  I do not have matching accounts/passwords on the XP and Win 7 boxes. Rather, I am using Simple File Sharing on XP and on the Win 7 box I (temporarily) turn off password protected sharing.  That arrangement appears to let me read/write folders that I have explicitly shared, but perhaps the index is located somewhere else and if so, is not getting properly updated.

    Friday, March 26, 2010 3:05 AM

Answers

  • Using "check file contents" took about an hour and a half to complete the "Preview" phase. This time, SyncToy wanted to rename 10,640 files and add 21,288 files.  I did not let this run. One of the more interesting results was that SyncToy claimed it "Found -10,340 files that did not require action." Perhaps this negative number will give you a clue to what was going on.

    I finally deleted the folder pair and created a new folder pair. 

    I selected the options to not include hidden or system files.  This time, the scanning and preview phases took only a few minutes. SyncToy wanted to copy about 50 files. In addition, SyncToy wanted to make copies of 10 files; that is, for a file named "E:\My Pictures\1234.jpg" SyncToy wanted to create a file named "E:\My Pictures\1234.1.jpg".  I let the operation "Run."

    I compared the 10 xxx.jpg files with the xxx.1.jpg files manually to confirm that they were in fact copies, and then deleted the 10 xxx.1.jpg files from E:\My Documents and ran SyncToy again. This time, SyncToy correctly wanted to delete those 10 files from the Win 7 laptop. I let this "Run."

    I ran SyncToy one final time and this time no operations were found to perform.

    It appears that my problem is now solved.  Somehow, the SyncToy metadata files became corrupted. Deleting the folder pair and then re-creating a new folder pair permitted SyncToy to create new metadata files.

    • Marked as answer by LemP Monday, March 29, 2010 8:34 PM
    Monday, March 29, 2010 8:33 PM

All replies

  • Hi LemP,

    Some similar problems happen if users had copied synctoy related files (I.E the hiden files looks like "SyncToy_xxx.dat" in sync folders) from one sync folder to another sync folder by accident. Such actions will confuse SyncToy.

    So I think we can begin in this direction. Would you please talk more about how you "added a Win 7 Pro x64 laptop"? Did you created new folder pairs between XP machines and Win7, or you atempted to "reuse" the existed folder pair between XP machines, and copied the "SyncToy_xxx.dat" files to Win7 machine folder?

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, March 26, 2010 3:21 AM
  • I created a new folder pair. However, the folder on the left side (XP machine) is the same folder that was being synchronized before.  That is, the original files are on partition E:\ of XP machine 1 and get synchronized to both XPLaptop and Win7Laptop (not at the same time, of course).  I did not copy any "SyncToy_xxx.dat" files, at least not deliberately.

    New folder pair:

         Left Folder:  E:\My Pictures

         Right Folder: \\Win7laptop\Users\username\Pictures

    Old folder pair:

         Left Folder: E:\My Pictures

         Right Folder: \\XPLaptop\mypixlap

    Friday, March 26, 2010 3:40 AM
  • The old folder pair should not influence the new one.

    Have you ever copied anything from "E:\My Pictures" or "\\XPLaptop\mypixlap" to "\\Win7laptop\Users\username\Pictures"? Is there any files already existed in the Win7 sync folder before you created the new folder pair?


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, March 26, 2010 3:47 AM
  • Yes. If I recall correctly, I manually copied all of the files from "E:\My Pictures" to "\\Win7laptop\Users\username\Pictures" before I created the folder pair.
    Friday, March 26, 2010 3:49 AM
  • Would you mind checking whether any "SyncToy_xxx.dat" in "E:\My Pictures" has been copied to Win7 folder as well, please?
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, March 26, 2010 4:03 AM
  • There is an old "SyncToy_xxx.dat" files in the Win7 folder, but it doesn't have the same name as any of the 3 "SyncToy_xxx.dat" files in the E:\My Pictures folder.

    None of those files indicate that they were modified today, when I last ran SyncToy.

    On the other hand, I searched the XP machine for the "SyncToy_xxx.dat" file that is in the Win7 folder and found a file with the same name on the XP machine in "C:\Documents and Settings\PJ\Local Settings\Application Data\Microsoft\SyncToy\2.0".  Of course, the file here is 6.45 MB and was modified today, while the file with the same name in the Win7 folder is only 16 bytes and was last modified in December.

    I assume that I should delete the "SyncToy_xxx.dat" file from the Win7 folder.  Should I delete all of the "SyncToy_xxx.dat" files from E:\My Pictures as well?

    Friday, March 26, 2010 4:22 AM
  • You can have a try. But for safety, you need to backup any "SyncToy_xxx.dat" before you delete it, and record where it was. Thus you can recover your environment if it does not work. (Please do not touch any file in "C:\Documents and Settings\PJ\Local Settings\Application Data\Microsoft\SyncToy\2.0")

    Another way maybe (Please notice that this way assums your problem were caused by "SyncToy_xxx.dat" files. So I do not recommend this way until we have made sure what caused this issue):

    1. Delete the folder pairs that involve Win7 sync folder.
    2. Delete all the "SyncToy_xxx" files in Win7 sync folder.
    3. Recreate folder pairs about the Win7 sync folder and sync them (The re-syncing action may cost a long time).

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, March 26, 2010 4:36 AM
  • So, what is the next step in determining what caused the issue?
    Friday, March 26, 2010 4:50 AM
  • I renamed the file in the Win7 folder from SyncToy_xxx.dat to SyncToy_xxx.dat.old.  The problem persisted.

    Unless you have another idea, I'm going to try your second method (deleting the SyncToy_xxx.dat in the Win7 folder and deleting the folder pairs that involve the Win7 folder), but not tonight.  I'll check back sometime tomorrow.

    Friday, March 26, 2010 5:02 AM
  • Thank you for your patience. Let's have a last try before applying my second method. Would you please list all the SyncToy_xxx.dat files, regardless whether it is old or not, in each of your 3 sync folders?


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, March 27, 2010 2:18 AM
  • At least part of the problem was caused by permissions on the Win 7 computer.  In one of my earlier posts, I said that the "Echo" operation appeared to run successfully, but that when re-ran the "Preview" operation, SyncToy wanted to copy the files again.  However, when I finally actually looked in the Win7 folder, I saw that the files had not been copied.  I adjusted the permissions until I could manually access the Win7 folder from the XP machine and ran SyncToy again.  This time, the "Echo" operation ran successfully and the files were actually copied.  When I re-ran the "Echo Preview" again, SyncToy correctly reported that no files needed to be copied.

    Correcting the Win 7 permissions did not solve the "Synchronize" problem, however.  When I changed the option to "Synchronize" and ran "Preview" SyncToy began "Adding an operation" for each file in the left folder (on the XP machine).  This ran very slowly, using 99% of the CPU cycles on the XP machine (it's only a 2.65 MHz P4) and I did not let it run to completion.

    To answer your questions about the SyncToy_xxx.dat files:

    There are 3 computers and 2 folder pairs (actually, I have another 2 folder pairs involving different folders, but I haven't run SyncToy using those pairs recently).  The left folder in each pair is E:\My Pictures.

    E:\My Pictures (3 SyncToy_xxx.dat files)

       SyncToy_012bfb5a-1dd2-439a-bda3-2a3992dafd0f.dat  16 bytes mod 6/30/09

       SyncToy_c09fd23f-b9ce-4216-bd55-b7bd7b74d34c.dat  16 bytes mod 12/9/09

       SyncToy_d464414e-d188-4643-87e6-7b3e2a0fa7da.dat  16 bytes mod 12/23/08

    \\Laptop\mypixlap  (XP Laptop)

       SyncToy_cc135c50-f6a9-411b-b16f-5787068514ef.dat 16 bytes mod 6/30/09

    \\PJ-T500\Users\PJ\Pictures (Win 7 laptop)

       SyncToy_b73abedb-0699-4649-aae7-8f6596155a63.dat 16 bytes mod 12/9/09

     

    There are several very large SyncToy_xxx.dat files in "C:\Documents and Settings\PJ\Local Settings\Application Data\Microsoft\SyncToy\2.0" on the main XP machine. These include:

      SyncToy_012bfb5a-1dd2-439a-bda3-2a3992dafd0f.dat 10 MB mod 12/9/09

      SyncToy_c09fd23f-b9ce-4216-bd55-b7bd7b74d34c.dat 8 MB mod 3/28/10 (today)

      SyncToy_b73abedb-0699-4649-aae7-8f6596155a63.dat 10.8 MB mod 3/28/10 (today)

      SyncToy_cc135c50-f6a9-411b-b16f-5787068514ef.dat 11 MB mod 12/9/09

     

     

    Sunday, March 28, 2010 6:15 PM
  • Thank you for the info, LemP. Now it is clear that your problem is not caused by the "SyncToy_xxx.dat" files (Sorry that I should ask you for the list to exclude this possibility at first).

    What did you mean "Adding an operation", about the synchronize mode. Did SyncToy try to delete these files, or mark them as "read only" or something?


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, March 29, 2010 12:58 AM
  • Thank you for the info, LemP. Now it is clear that your problem is not caused by the "SyncToy_xxx.dat" files (Sorry that I should ask you for the list to exclude this possibility at first).

    What did you mean "Adding an operation", about the synchronize mode. Did SyncToy try to delete these files, or mark them as "read only" or something?


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, March 29, 2010 12:59 AM
  • What I meant was that at the bottom of the "Preview" screen there is what I would call the Status Bar, and below that is a progress bar.

    When the Preview is run for a Synchronize operation, the status bar initially shows "Looking for changes ..." in the folder pair and subfolders.  After the "Looking" phase is complete, the Status Bar shows "Adding an Operation for ..." listing each of the files and folders that will be operated on.

    This phase of the preview proceeds reasonably quickly until the progress bar indicates that the preview operation is a little more than 1/2 complete. At this point, the operation stalls. Instead of quickly "Adding an operation ..." for file after file, the Status Bar stays on the same file name for multiple minutes. Because this was taking so long, I had canceled the operation.

    In order to answer your question, I let the Preview operation run to completion. It took over an hour. At the end, it reported that it wanted to delete 214 folders and 5400 files, rename 4 files, and create 215 new folders and 5416 new files.  All of these operations were in the E:\My Pictures folder.  Essentially, it seems to want to delete about half of the contents of E:\My Pictures and then copy them back from the right folder (which is on the Win 7 laptop).  According to Windows Explorer, E:\My Pictures has 430 folders with 11,601 files.

    The problem may not be the SyncToy_xxx.dat files, but it doesn't seem as if things would be much worse if I simply delete the folder pair and create a new folder pair.

    Monday, March 29, 2010 3:44 AM
  • Hi LemP,

    "Essentially, it seems to want to delete about half of the contents of E:\My Pictures and then copy them back from the right folder (which is on the Win 7 laptop)" this remind me that there are reports these days, that Daylight Saving Time (DST) might cause some problems which looks similar to your issue. For instance, http://social.microsoft.com/Forums/en-US/synctoy/thread/c497c391-926f-497e-9c0d-a1a1a283652a. Is it possible that you are suffering Daylight Saving Time issue, too?

    (There seems no methods to work around DST issue so far, because it is difficult to repro and debug. We are trying to collect enough information from custormers to fix it. ) 

    I have no other ideas yet, because your problem rarely happens. If you can make sure none of your files would miss during the sync session, I think you can try runing sync and then seeing if such issue still happens. It is recommended that you do some back up before you trying this (you need not do back up work again once everything goes well).

    Thanks


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, March 29, 2010 9:41 AM
  • I haven't noticed this issue before, but I didn't have the Win 7 computer prior to the change from DST to standard time last fall.  Also, unlike the post from "manveruppd ", SyncToy doesn't want to synchronize all of the files, only about half of them.  There is no problem running SyncToy to synchronize the folder pair on the two XP machines, so I suspect that DST is not my issue.  That fact, plus the fact that the "Preview" operation slows down so dramatically about half-way through, makes me suspect that that the SyncToy metadata file for this folder pair has become corrupted in some way.

    I plan on doing the following:

    • run another "Synchronize" preview and inspect the time stamps of the files that SyncToy wants to delete. If I can detect any pattern (compared to the files that it doesn't want to delete), I'll let you know.
    • delete the folder pair between E:\My Pictures and the folder on the Win 7 machine, create a new folder pair, and run Synchronize.  I have a separate backup of E:\My Pictures, just in case.
    Thanks for your help.  I'll post back with the results.
    Monday, March 29, 2010 3:03 PM
  • Interesting.  It DOES seem to have something to do with DST, although (a) not all of the files are involved and (b) it is not only recent files.

    Something peculiar is going on with the date stamps on some, but not all files (NTFS in all cases). Here is an example of the properties of one particular file:

    Using Windows Explorer on the XP machine (where E:\My Pictures is located) and looking at the file and its containing subfolder on the XP machine:

    • folder created 6/30/09
    • file created 1/29/05 5:05:38 pm
    • file modified 11/16/01 9:13:58 pm

    I can't explain explain why the file was "modified" 4 years before it was "created." The reason that its containing folder is dated so recently is because all of the files at issue here were originally in a different partition (on the XP machine) and I moved them to the E:\ partition last June.

    Using Windows Explorer on the XP machine to view the corresponding file on the Win 7 laptop over the network connection, the properties of the same file and its containing folder are the same:

    • folder created 6/30/09
    • file created 1/29/05 5:05:38 pm
    • file modified 11/16/01 9:13:58 pm

    However, if I go to the Win 7 laptop itself, and use Windows Explorer there to look at the same file, I see:

    • folder created 6/30/09
    • file created 1/29/05 4:05:38 pm
    • file modified 11/16/01 8:13:58 pm

    On the SyncToy Preview screen (run on the XP machine) the file that SyncToy wants to create in E:\My Pictures on the XP machine is shown as "modified 11/16/01 8:13:58 pm".

    I can't explain why the XP machine and the Win 7 machine show different time information for the same file stored on the Win 7 machine.  Both machines display the correct time and date in the system notification area, and both indicate that DST is currently in effect.  I understand that, at least prior to Win 7, NTFS stored file time information relative to 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC) and that the OS translated this to the correct local time. Perhaps something changed in the way that Win 7 handles file time stamps.

    I saw a thread somewhere on this forum that suggested using the option to check file contents. I realize that this may take a very long time, but I think I'll try it before I delete the folder pair.

     

     

    Monday, March 29, 2010 5:24 PM
  • Using "check file contents" took about an hour and a half to complete the "Preview" phase. This time, SyncToy wanted to rename 10,640 files and add 21,288 files.  I did not let this run. One of the more interesting results was that SyncToy claimed it "Found -10,340 files that did not require action." Perhaps this negative number will give you a clue to what was going on.

    I finally deleted the folder pair and created a new folder pair. 

    I selected the options to not include hidden or system files.  This time, the scanning and preview phases took only a few minutes. SyncToy wanted to copy about 50 files. In addition, SyncToy wanted to make copies of 10 files; that is, for a file named "E:\My Pictures\1234.jpg" SyncToy wanted to create a file named "E:\My Pictures\1234.1.jpg".  I let the operation "Run."

    I compared the 10 xxx.jpg files with the xxx.1.jpg files manually to confirm that they were in fact copies, and then deleted the 10 xxx.1.jpg files from E:\My Documents and ran SyncToy again. This time, SyncToy correctly wanted to delete those 10 files from the Win 7 laptop. I let this "Run."

    I ran SyncToy one final time and this time no operations were found to perform.

    It appears that my problem is now solved.  Somehow, the SyncToy metadata files became corrupted. Deleting the folder pair and then re-creating a new folder pair permitted SyncToy to create new metadata files.

    • Marked as answer by LemP Monday, March 29, 2010 8:34 PM
    Monday, March 29, 2010 8:33 PM
  • P.S.: I haven't confirmed this (and may not any time soon), but it appears that if you attempt to sync to a folder for which you do not have the correct read/write permissions set, SyncToy thinks that there are no files or folders in the right hand folder (because it can't read them without permission) and then wants to delete all of the files and folders in the left hand folder.  Once this happens, the SyncToy metadata files become corrupted, such that even if you do grant r/w permission to the right hand folder, SyncToy still wants to delete the files and folders in the left hand folder. At this point, the folder pair must be deleted and re-created.
    Monday, March 29, 2010 9:51 PM
  • Hi LemP,

    I think your deduction is right. We will try to verify it. Sorry that I had put you in a wrong direction. I had never met such issues before.

    Glad to see your issue has been resolved, anyway. Your information will also help the other users who have similar problem.

    Thanks very much!


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, March 30, 2010 12:14 AM