Answered by:
SyncToy Ver 2 File Time Errors

Question
-
Have used version 1.4 very successfully. Just tried 2.0 and I am getting a 5 hour error between identical files in 2 folders.
I moved files from an older PC to a new PC using a thumb drive. I copied the entire contents of the thumb drive to drive "E" on the new PC. Drive E is a logical drive in an extended partition. Using Windows XP Pro on the PC. The newPC has SyncToy 2.0
The files I copied had two layers of folders. Using Windows Explorer the contents of the thumb drive and Drive E were identical. Then I wanted to sync the folders using SyncToy 2. The preview shows a 5 hour discreptancy on the file times.
The PC that was the source of the files on the thumb drive is using SyncToy 1.4. Both PCs are set to same time GMT -5:00 with daylight savings set to adjust automatically.
I have since uninstalled 2.0 on the new PC and installed 1.4. Everything works fine.
Because the file time error was 5 hours and my GMT is also 5 I assume there is a connection.
Years ago I had 1 hour errors on another program due to daylight savings/standard time but that issue seems to have gone away.
I will stick with 1.4 until I hear there is a fix for this issue.
Thank you.Saturday, March 7, 2009 4:50 PM
Answers
-
Hi Dave,
I think this might explain your issue. From the FAQ on this forum:
Q. On the first sync after upgrade from SyncToy 1.4 or 2.0 Beta, where one endpoint is on a FAT16/FAT32 drive (e.g. memory stick or USB key), SyncToy 2.0 wants to re-synchronize all files because the file times look different. What can I do about it?
A. The issue arises from the fact that SyncToy 2.0 has to re-create the folder pair metadata after the upgrade and FAT reports file times in local time and NTFS reports UTC times. There are a couple of *one-time* workarounds to fix this issue:
1) Go ahead and let the folder pair re-synchronize all files (i.e. hit Run on the Preview window and let it complete). This should be ok since you should have done a successful sync before upgrade. This “long” sync will only be required once after the upgrade, since SyncToy will ensure during this sync that the timestamp metadata is reconciled on both sides. After this you’ll start seeing normal SyncToy behavior for these folder pairs.
2) Temporarily change options on your folder pair to “Check file contents” and Run the folder pair. This will only copy the files where the content is actually different – but it will take more time to analyze the files since it will have to compare the file contents. Once this sync is done, you can uncheck the option and continue normal operation.
- Marked as answer by Deepa Choundappan Wednesday, March 11, 2009 7:38 PM
Monday, March 9, 2009 6:22 PM
All replies
-
Hi Dave,
I think this might explain your issue. From the FAQ on this forum:
Q. On the first sync after upgrade from SyncToy 1.4 or 2.0 Beta, where one endpoint is on a FAT16/FAT32 drive (e.g. memory stick or USB key), SyncToy 2.0 wants to re-synchronize all files because the file times look different. What can I do about it?
A. The issue arises from the fact that SyncToy 2.0 has to re-create the folder pair metadata after the upgrade and FAT reports file times in local time and NTFS reports UTC times. There are a couple of *one-time* workarounds to fix this issue:
1) Go ahead and let the folder pair re-synchronize all files (i.e. hit Run on the Preview window and let it complete). This should be ok since you should have done a successful sync before upgrade. This “long” sync will only be required once after the upgrade, since SyncToy will ensure during this sync that the timestamp metadata is reconciled on both sides. After this you’ll start seeing normal SyncToy behavior for these folder pairs.
2) Temporarily change options on your folder pair to “Check file contents” and Run the folder pair. This will only copy the files where the content is actually different – but it will take more time to analyze the files since it will have to compare the file contents. Once this sync is done, you can uncheck the option and continue normal operation.
- Marked as answer by Deepa Choundappan Wednesday, March 11, 2009 7:38 PM
Monday, March 9, 2009 6:22 PM -
The second suggestion does not work for me, it still wants to overwrite all files.Thursday, March 31, 2011 4:39 PM