none
time of file in syhctoy 2.0

    Question

  • I just upgraded to synctoy 2.0 from 2.0 beta.

     

    I followed instructions and did a sync before I upgraded.

     

    Now, synctoy says that all the files need to be replaced because they are 4 hours off.

     

    I went back and checked the files and the files are the same time when I look at them in explorer, they have the same time.

     

    What is happening. I live in the Eastern (U.S.) time zone.

     

     

    Saturday, August 16, 2008 1:22 PM

Answers

  • You are right about the incorrect display of modification times. We will aim to correct this in a future release of SyncToy.

     

    You are also right about the fact that whether the files were created on FAT or NTFS affects our ability to detect if the files are truely identical.

     

    The bug where you point out the summany is not a bug because we looked on both sides and reporting a count of files on both side and are reporting that both sides do not require a change.

     

    "synctoy 2.0 displays

    Found 294 files that did not require action.

    Avoided copying 4,654,540 in 294 files.

    dir  displays

                 147 File(s)      2.327.270 bytes"

     

    Thanks

    Deepa

    Monday, September 15, 2008 6:06 PM
    Moderator

All replies

  • Can you let us know the file system types on both sides? Are they NTFS or FAT32? You can check this from the Disk Management page in the Computer Management Control Panel applet.

     

    Also, you can try out a small experiment. Do a preview again of your folder pair and uncheck all operations except one file that's showing this difference. Do a run, allowing SyncToy to sync just that one file. Now check the file times and contents against through Explorer and make sure they are the same. Finally, do a Preview again that same folder pair and see if that file no longer shows up.

    Sunday, August 17, 2008 5:31 PM
    Answerer
  • Hi, I'm also having the same problem too.  I've been previously using the 2.0 beta.  Now after installing the new 2.0, it's reporting that the time is off by 4 hours.  I'm synchronizing between my flash drive (FAT32) and a network drive (not sure which system it is).  The time is off on the network drive by four hours.
    Monday, August 18, 2008 8:21 PM
  • Just to follow up, sometimes it reports it being off by four hours, sometimes it doesn't, it's not consistent.  Generally, when the file is changed in the network drive, it reports it being off by fours.  However, on the flash drive, it's consistent with the local time.  Of note, changes in the file in either location are correctly flagged and synchronized.
    Monday, August 18, 2008 8:29 PM
  • I can confirm this issue upon upgrade to v2.0 from v2.0 beta.

    What I have done, step-by-step:


    1: Synced folders (one on desktop, NTFS) and one on flash drive (FAT32), using v2.0 beta.

    2: Upgraded to v2.0 final by running the exe (and letting it update itself).

    3: Attempt to sync again with v2.0 installed.

    3a: Clicked "Preview" to get a list of files to be updated.


    At this stage, previewing the files to be updated, I too have the issue with incorrect "last modified" dates, requiring practically all files to be overwritten.


    I tried to replicate the issue by doing this:

    1: Deleted the entire folder from my desktop computer, and re-copying the entire folder from the flash drive. Now these two folders will be identical, physically.

    2: Created a new folder pair.

    3: Synctoy (v2.0 final) shows the same thing... requiring a huge list of files needing to be updated.


    Interestingly enough, the "last modified" file on the COMPUTER is wrong, with the timestamps on the flash drive being correct - computer timestamps are all set to 'future' times, including a date that has not even occurred yet for me ('last modified' for one file being 20 August, at time of writing it is 19 August where I live).


    So importantly, these incorrect 'last modified' dates have appeared DESPITE me physically copying the folder over from my flash drive onto my computer.

    I went ahead and clicked for it to run anyway, to see what would happen (I had a backup). The files overwrote completely, and then I modified two files.

    Previewing NOW shows the same problem! Incorrect last modified date on my computer files, but the CORRECT dates on my flash drive.

    It seems as though Synctoy is giving my computer files some sort of incorrect last modified dates... but the flash drive modified dates remain correct, even after overwriting them with computer files.

    This was from computer files being modified, and updating them TO the flash drive.

    I have just tested modifying a file on the flash drive, and clicking Preview to see how it will update to the computer - so going the other way this time. The times are correct, as they should be.


    Hope that can be helpful in trying to find out what is going on.


    dewaaz


    Tuesday, August 19, 2008 9:28 AM
  • me too,but i have 8 hour past, the original file has 8 hours past than target file.
    after i test , this happen whent the source file is in ntfs and target is in fat32.
    is a bug?? BTW,I lost my beta file pairs...

    Tuesday, August 19, 2008 10:29 AM


  • I just uninstalled v2.0 final, duplicated my folder between flash drive and desktop, installed 2.0final and the same issue appeared Sad


    I then uninstalled v2.0final and installed v2.0beta - worked with no issues, even after testing with a few modified files.


    Looks like it's beta for me until this is resolved Smile hehe


    At least the beta's never given me any problems, so I'm not complaining Big Smile

    If anyone wants to revert to v2.0beta and can't find a link (I couldn't, until I found one somewhere on my PC) - here's a link:

    <<-- taken out by moderator - users are not allowed by SyncToy License Terms to post SyncToy builds for download anywhere >>

    there shouldn't be a problem linking to the old beta, not at least until this issue with the 2.0final is resolved.


    thanks to the synctoy team for such a great app, i don't know where i'd be without it Big Smile

    Tuesday, August 19, 2008 11:41 AM
  • Deewaz, if you posted the 2.0 Beta file for download above, please take it down. The SyncToy License Terms do not allow you to re-post the setup file for download by others. We will work on your issue regarding the timestamp and see if we can fix it or find a workaround for you so you can continue using the final 2.0 build.  

    Wednesday, August 20, 2008 6:15 PM
    Answerer
  • I'm having the same problem too. The timestamp difference is the difference between my time zone and GMT. This started after upgrade synctoy from 2.0 beta to 2.0 final build.

     

    Wednesday, August 20, 2008 10:34 PM
  • Hi -

     

    It looks like that the problem appears when you upgrade to the Sync 2.0 version for a folder pair that synchronizes files between NTFS and FAT volumes only (please let us know if you’re seeing this with NTFS-NTFS sync). The issue arises from the fact that we have to recreate 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)      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 must have done a successful sync before the upgrade anyway. 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)    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.

     

    It may “appear” that this issue does not exist on the 2.0 Beta version, but if you go back to using the Beta version you’ll run into the same issue twice a year on DST changes. The better solution is to upgrade to the 2.0 final build, do the one-time “long” sync and resolve the issue for good

     

    Thanks

    Deepa

    Thursday, August 21, 2008 3:23 AM
    Moderator
  • Yes. The Flash drive is FAT while the hard drive is NTFS.

    I solved the problem with the following steps.

    I create a new folder pair to have the hard drive echo to the flash drive (to make sure that I did not inadvertently change anything on my hard drive). Then I did a preview which showed that 3,000 + files were off by 4 hours (there were a total of 6,000 + files but only about half needed to be synced). I held my breath and ran the sync and nothing happened. No files were changed notwithstanding the preview saying that 3,000 + needed changing. After that the error went away.

    I did the same thing with another flash drive that I use for syncing, and the same thing happened.

    Strange!
    Saturday, August 23, 2008 1:26 PM
  • *one-time* workaround #2 did not work for me. It appears that SyncToy erroneously reports the filetime from NTFS in UTC while correctly reporting the filetime from FAT in local time (or maybe it's vice-versa). I'm using ST for the first time, version 2.0.100.0. I had been playing with XCOPY and ran into problems using it to synch between the two file systems because it would cause an error of up to 2 seconds in the Last Modified time when copying and also updated the Created time to current. XXCOPY has the same error but has a workaround for deciding what files have changed by ignoring discrepancies of up to 2 seconds. Nevertheless, Windows File Properties always shows essentially the same Last Modified time for files copied between NTFS and FAT32, in local time.

     

    So I was amazed when SyncToy reported a 4 hour difference on all files that had been copied over. NTFS time was consistently 4 hours less than FAT32 time as reported by ST - now that is fundamentally wrong no matter which way you look at it. I'm in the Eastern Time Zone and UT is 4 hours greater than EDT. The code is mishandling time - period! 

     

    Tried #2 and it behaved exactly the same whether "Check file contents" was set or not - i.e., all those 4 hour differences triggered an overwrite action. The files had to be overwritten just as for #1.

     

    Tom

    Monday, August 25, 2008 10:46 PM
  •  ve3meo wrote:

    So I was amazed when SyncToy reported a 4 hour difference on all files that had been copied over. NTFS time was consistently 4 hours less than FAT32 time as reported by ST - now that is fundamentally wrong no matter which way you look at it. I'm in the Eastern Time Zone and UT is 4 hours greater than EDT. The code is mishandling time - period! 

     

    It seems that a file created in one folder of a NTFS-FAT32 pair and copied by any means other than SyncToy to the other folder in the pair results in a SyncToy action to Overwrite the FAT32 file and the ST Preview to incorrectly report the NTFS file's Last Modified time as 4 hours less than the time correctly reported for the FAT32 file. After synchronization by ST, you can delete either NTFS file or FAT32 file and copy across again by any other means and this time SyncToy thinks the files are identical. Why can't ST get it right the first time when Windows File Properties has no difficulty?

     

    To illustrate the confusion:

    1. Sync via ST a file across the NTFS-FAT32 pair and confirm in another Preview no further sync action needed.

    2. Delete the NTFS file and copy the FAT32 across to replace it.

    3. ST-Preview and now you see two actions where none should be required: a Delete and a New (with that -4 hr error) and does not even report the Last Modified time for the Delete Target (that's an oversight! - could be important to the decision to uncheck the action)

    4. Uncheck the Delete action and Run ST. The Results report is that the ST Run "completed successfully" but on exam of the table, no action succeeded or failed and 1 operation was skipped because it was unselected after preview (the Delete). Apparently, the Run module for the New action detected that a target file of the same name existed and so skipped the New action without reporting (see #6 below) what should have been a Fail.

    5. Repeat #3 and then Run ST. Now ST needlessly deletes the FAT32 file and copies the identical NTFS file over. Two actions that were unnecessary, wasteful and risky, all because there is some mishandling of filetime.  

    6. Repeat steps 1-3 using a file that was modified more than 4 hours ago (or whatever your offset is from UT but in the opposite direction). Now edit the NTFS file - its Last Modified Time, even as far as ST is concerned, should now be later than that for the FAT32 file. Repeat step 4 - same results and the folders remain truly not in sync. In this case the Delete-New pair of actions were necessary to achieve sync but could/should have been interpreted as an Overwrite - that would obviate some potential confusion.

     

    Fix the handling of time stamps and that "one-time" startup sync that throws everybody off when they know the folders are identical will be a minor, not a major action. And maybe the same fix will result in Delete-New pairs becoming interpreted as Overwrites, not quite so mind-numbing.

     

    Tom 

    Tuesday, August 26, 2008 2:22 PM
  • Here's a link to a discussion of the timestamp diffs between FAT and NTFS. It supports my contention that SyncToy is initially misinterpreting one of the file systems timestamps for files copied from one system to the other by means other than SyncToy.

     

    Tom 

    Tuesday, August 26, 2008 6:23 PM
  • Waiting for a bug fix.

     

    Repro case:
    create a folder pair,
    left folder on NTFS has some files,
    right folder on FAT32 is empty.
    Preview seems to add UTC offset twice to file modification, e.g.
    UTC modification time is 10:09 (12:09 in Western European DST, UTC+2)
    Synctoy displays 14:09 on preview.

     

    Suggestion:
    advise against use of FAT32 in help and when creating a new folder pair: "Use FAT32 at your own risk"
    as deepa mentioned above, FAT32 stores file modification times in local time,
    but local time changes twice a year when daylight saving time is turned on or off.

     

    Friday, September 12, 2008 10:38 AM
  • I believe we have two bugs here.

     

    Number one is the incorrect display of modification times I described in my first post.

     

    Number two is that synctoy 2.0 wants to update only some files with equal modification date when comparing NTFS with FAT32, but not all.

     

    I have created a folder pair left NTFS - right FAT32 with 148 files I had copied manually before.

    synctoy preview wants to update exactly 107 files, but not the remaining 41. The 41 files have a modification time with nonzero fractional seconds, the other 107 have zero fractional seconds (they were probably originally created on FAT32 which stores modifications up to a precision of even seconds).

    I have used the cygwin command find to display the modification times including the fractional part, I don't know of a windows command to do that.

    C:\cygwin\bin\find joetest.trc -printf "%t %TZ %p\n"
    Mon Jun 23 09:56:48.0000000000 1997 WEDT joetest.trc

     

     

     

    Saturday, September 13, 2008 6:59 AM
  • Another bug

    summary display counts files twice

    synctoy 2.0 displays

    Found 294 files that did not require action.

    Avoided copying 4,654,540 in 294 files.

    dir  displays

                 147 File(s)      2.327.270 bytes

     

    Monday, September 15, 2008 5:43 AM
  • You are right about the incorrect display of modification times. We will aim to correct this in a future release of SyncToy.

     

    You are also right about the fact that whether the files were created on FAT or NTFS affects our ability to detect if the files are truely identical.

     

    The bug where you point out the summany is not a bug because we looked on both sides and reporting a count of files on both side and are reporting that both sides do not require a change.

     

    "synctoy 2.0 displays

    Found 294 files that did not require action.

    Avoided copying 4,654,540 in 294 files.

    dir  displays

                 147 File(s)      2.327.270 bytes"

     

    Thanks

    Deepa

    Monday, September 15, 2008 6:06 PM
    Moderator
  • I am also suffering from this problem post upgrade and it is extremely affecting my ability to use SyncToy.

    Please let us know if we could expect a bugfix soon!

    Thursday, January 22, 2009 5:07 PM
  • Wow, there is no end to problems when MS tries to improve a program. 

    I was using Briefcase happily for years and years, starting with Windows95 and through XP.  Then I got Vista (not by choice, but you can't get a computer these days without it unless you want to pay EXTRA for discontinued XP).  Briefcase is included with Vista, but doesn't work.  Skips files, etc.  So I resort to SyncToy 2.0.  Just got it the other day.  And I have the same problems with overwriting files that haven't been changed. 

    I have about 3.5 GB of files I keep on a flash drive that I use to keep files at home and work synced.  This worked beautifully in Briefcase, and took anywhere between seconds and a few minutes depending how many files I was syncing.  But SyncToy checks and overwrites thousands of files that do not need updating.  Now it takes HOURS to do a sync. 

    My flash drive is Fat32.  Why not also format is NTFS?  Because elsewhere on an MS site it said that this could create problems with compatibilty across systems.  I can't afford to have corruption on my work files.

    I sure hope you can find a fix.  I guess I will go back to SyncBack...once this 6 hour SyncToy update finishes.
    Friday, January 30, 2009 2:47 AM
  • Hi.

    This is now MAY 2009. Are there any solution or a small upgrade for this buggy SyncToy 2.0? I really don't want to sync the whole 300GB of data... The installer on the download page is very much still the same release back in August 2008, which also means the time problem is still there.

    You see, not everyone is leaving in GMT timezone you know...
    Sunday, May 10, 2009 2:06 PM
  • That's It - I gave up - Switched to Freefilesync from sourceforge. It has 2 sec timestamp margin and a new look upon sync'ing - and it worked! A crude GUI, though.

    Friday, May 22, 2009 4:08 PM
  • This time difference bug makes Synctoy 2.0 almost worthless as a synchronization tool, and that's really sad...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).

    Thanks for the tip, BirgerM. Synctoy 2.0 was really making me go insane...
    Saturday, July 11, 2009 2:52 PM
  • An additional note: Check out Allway Sync...seems to be doing the job pretty well.

    PS. Syntoy Team: Fix Synctoy 2.0 already!....please!
    Saturday, July 11, 2009 3:47 PM
  • It is the NTFS time that is reported incorrectly.
    Also note that the time reported in SyncToy is using US format. (eg the last run time)  It is completely ignoring my Vista locality settings. 

    So maybe that is the root of the problem with time zoning....

    Please dont be US centric all the time !    If a default is needed, use dd/mmm/yyyy  so there can be no ambiguity.
    Monday, July 13, 2009 1:39 AM
  • I just checked the time difference which is wrongly detected by Synctoy in the files from different drives: it is exactly 5 hours -> the exact difference between GMT-5 (my time zone) and GMT. I don´t know why does it behave that way, but it s definitely wrong.

    Note: I am working with 2 external HDDs, both with FAT32. My Windows partition is NTFS.
    Monday, July 13, 2009 2:00 AM
  • I use a program to file synchronization, which is called File Sync. File sync program (http://www.fileutilityblog.com/archives/240) is one of the most efficient programs of all that I know. That is why I use this program and haven't any problems.
    Friday, November 13, 2009 2:09 PM
  • I just checked the time difference which is wrongly detected by Synctoy in the files from different drives: it is exactly 5 hours -> the exact difference between GMT-5 (my time zone) and GMT. I don´t know why does it behave that way, but it s definitely wrong.

    Note: I am working with 2 external HDDs, both with FAT32. My Windows partition is NTFS.
    Exactly!

    I for me SyncToy 2.1 detects one hour difference on every file, and that is the difference between my timezone, CET, and GMT. I am trying to sync a FAT32 SD card with a folder on my NTFS C-drive.
    Tuesday, December 22, 2009 10:09 PM