Problem with saving time again?

Help
2014-06-30
2014-08-13
  • Agustin Lobo
    Agustin Lobo
    2014-06-30

    I have lots of files marked to be copied that have just 1h of difference with those
    that had already been synced in the past.
    I guess this is the saving time problem again, was this problem not fixed?
    Is there a fix to avoid copying all this files? I'm using
    5.23 on linux.

     
  • Zenju
    Zenju
    2014-06-30

    It's fixed on Windows, but not on Linux/OS X because it should generally not occur there. In particular it can still occur when interacting with Windows, e.g. accessing a FAT32 formatted USB drive. It seems we need something better here.

     
  • Stefan
    Stefan
    2014-06-30

    accessing a FAT32 formatted USB drive. It seems we need something better here.

    I would highly welcome a different way of dealing with this.
    Maybe an automatic flag that allows to isolate all exact 1h differences? So it were easier to mark them all in one go - to exempt them from the list, for instance.

    https://sourceforge.net/p/freefilesync/discussion/help/thread/d5f64ad9/

     
  • Agustin Lobo
    Agustin Lobo
    2014-06-30

    The disk I use to backup to is an external 2Tb FAT32, and the files are copied from another external
    20 Gb NTFS disk and sometimes from the ext linux partition.
    Am I always going to have this issue with this disk? I can't believe it came
    as a FAT32, I did not format it myself. Is there any solution other than repeating syncs? Perhaps omitting the files with the exact 2h difference could be a way to circumvent the problem...

     
  • Zenju
    Zenju
    2014-07-01

    I don't think it's possible to reliably detect +-1h differences. OTOH I'm not sure if a less than 100% reliable automatism is sufficient.
    Maybe this is a problem that must be solved by the user alone. The time offset is dependent on the file system of a particular folder, usually FAT32, so this could indicate a need for a new comparison option at folder pair level.

    Maybe a list of offsets for the user to enter is the solution: 1h, 2h, depending on what he is seeing and deeming acceptable in a particular scenario. This could also be sufficient for more difficult problems like additional fixed offsets (+-3h, +-4h, ect.) due to time zones with FAT32.

     
  • Stefan
    Stefan
    2014-07-01

    Omitting exact hour differences (as a saved OPTION with particular sync jobs) sounds good. I think these switches are the reason why other software doesn't flag those files as different.

    OFFsetting, however - I don't know. Maybe I didn't get the point? If you mean to offset the time of whole folder contents - that seems too risky for my scenarios. I also run partial syncs, from FAT to FAT and to subfolders and also plain pure copies of files. Not all my files are off by exact hours.

     
  • Zenju
    Zenju
    2014-07-29

    I've added this option for the next 6.8 release. Here's the new beta for testing:
    http://freefilesync.sourceforge.net/FreeFileSync_6.8_beta_Windows_Setup.exe

     
    • Stefan
      Stefan
      2014-07-30

      GREAT. Been testing it on some problematic drives and it took care of all issues. Differences in seconds are still respected - so this really works nicely as far as I can tell. I really appreciate this feature.

      What do you mean by "Support for high dpi display settings"?
      On my 1920x1200 laptop the icons look large enough (same as before) but the font size in main window and lower left presets are as tiny as ever.

       
  • rwinston
    rwinston
    2014-08-13

    Not sure how v6.8 will work with previously created mirror files on FAT USB stick using v 6.7 and earlier. Example files - USB files created using v6.7 and earlier in mirror mode:

    file created 27 February 2014 (no DST):

    on NTFS HDD: created / modified / accessed - all 27 February 2014 20:50:16

    on FAT USB stick: created 30 July 2023 01:37:24, modified 27 February 2014 19:50:18
    accessed 26 February 2014

    NOTE: file modified time on USB is not exactly 1 hour different from NTFS HDD, it is 1 hour and 2 seconds.

    File created 12 August 2014 (DST in operation):

    on NTFS HDD: created 12 August 2014 21:07:59, modified 12 August 2014 21:08:00, accessed 12 August 2014 21:07:59

    on FAT USB stick: created 08 December 2024 23:00:34, modified 12 August 2014 21:08:02,
    accessed 13 August 2014

    In this case USB file modified time is 2 seconds different from the NTFS HDD.

    I assume the 'funny' creation and access date/time are the result of the v6.7 and earlier metadata modifications. But will v6.8 look at the 'modified' dates and even with a setting to ignore a one hour difference, take these files as different - because of the 2 second deviation?

    Having updated to v6.8 but then read the change log more carefully, I decided not to use v6.8 yet until I understand this time issue better and I have now gone back to v6.7. Thanks at least for an installer that allows an older version to overwrite a newer version.

     
    • Zenju
      Zenju
      2014-08-13

      I assume the 'funny' creation and access date/time are the result of the v6.7 and earlier metadata modifications.

      Yes. With v6.8 the old DST hack is gone (until further). The new handling is very simple: In addition to checking file modification times (with a 2 sec tolerance), you can opt-in to also consider a shift in file modification times of a given number of hours as equal (also with 2 sec tolerance).