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.
Problem with saving time again?
- Posts: 8
- Joined: 27 Jan 2009
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
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.
- Posts: 85
- Joined: 28 Aug 2012
> 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.
viewtopic.php?t=178
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.
viewtopic.php?t=178
- Posts: 8
- Joined: 27 Jan 2009
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...
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...
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
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, etc.) due to time zones with FAT32.
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, etc.) due to time zones with FAT32.
- Posts: 85
- Joined: 28 Aug 2012
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.
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.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
I've added this option for the next 6.8 release. Here's the new beta for testing:
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.8_beta_Windows_Setup.exe]
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.8_beta_Windows_Setup.exe]
- Posts: 85
- Joined: 28 Aug 2012
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.I've added this option for the next 6.8 release. Here's the new beta for testing:
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.8_beta_Windows_Setup.exe]Zenju
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.
- Posts: 1
- Joined: 13 Aug 2014
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.
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.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> I assume the 'funny' creation and access date/time are the result of the v6.7 and earlier metadata modifications.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.winst01
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).
