Hi,
I use FFS and a portable USB drive to sync a directory tree between two computer running Macosx.
Until last week everything worked perfect, FFS is a great help!
Since yesterday FFS wants to copy all my files, aven thos that have not been changed for years. I allowed that on on of the machines (at home). Now, it tries to do the same at the office computer. I found that the modification date and time of the topmost folder on the USB drive is changed to the actual time every time when I press the sync button in FFS. I changed the modification time using 'touch' to an older date, but when I press 'sync' it is again modified to the actual time and date. Therefore FFS always thinks that all files and folders below this topmost folder have been modified.
Maybe not related, but the error occured starting from the first day after the daylight saving clock change to summer time.
Best regards
Thommi
FFS changes modification date/time of base folder, then wants to sync all files
- Posts: 3
- Joined: 31 Mar 2014
- Posts: 3
- Joined: 31 Mar 2014
After further investigating the problem, I am almost shure that it relates to daylight saving. There is a post on this forum saying that there is a 'global setting to "ignore +-1h"'. The helpfile explains that FFS automatically corrects for the problems arising from daylight saving, but it explicitly refers to Windows systems and the way that FAT and NTFS store time information. My problem occured on two MacOs systems, each syncing to a FAT USB disk.
I really need some help with this, I can not find any settings that I could change.
Thank you for your time and for this great piece of software.
Thommi
I really need some help with this, I can not find any settings that I could change.
Thank you for your time and for this great piece of software.
Thommi
- Posts: 85
- Joined: 28 Aug 2012
I don't think there is an actual setting to ignore 1h differences, although I wish it were. From time to time (no pun intended) I run into the same problem when syncing old drives that carry various DST time stamps.
Quoting the help file:
In order for FreeFileSync to start handling DST and timezone differences, an initial full synchronization is required. Subsequent syncs will then never show a time difference again for unchanged files.
Did you try that? Don't know if this applies to MacOS as well.
Quoting the help file:
In order for FreeFileSync to start handling DST and timezone differences, an initial full synchronization is required. Subsequent syncs will then never show a time difference again for unchanged files.
Did you try that? Don't know if this applies to MacOS as well.
-
- Site Admin
- Posts: 7212
- Joined: 9 Dec 2007
> Don't know if this applies to MacOS as well.
Currently the automatic DST handling is implemented on Windows only. Even there it's not a 100% solution, but enough to ease the pain with DST switches and time zone changes *most* of the time. A better solution needs yet to be found:
[404, Invalid URL: https://sourceforge.net/p/freefilesync/feature-requests/235/]
Currently the automatic DST handling is implemented on Windows only. Even there it's not a 100% solution, but enough to ease the pain with DST switches and time zone changes *most* of the time. A better solution needs yet to be found:
[404, Invalid URL: https://sourceforge.net/p/freefilesync/feature-requests/235/]
- Posts: 3
- Joined: 31 Mar 2014
Yes, initially I did a full copy-sync.
So I think the best way to deal with this challenge is to have my files in sync prior to DST changes, an then perform one full copy afterwards.
As a workaround, I changed the time difference tolerance in the config file to 3602 seconds, which allows me to get my files synced.
Zenju, thank you very much for your work! The differences between FAT, NTFS and the interactions with DST are really a pain!
So I think the best way to deal with this challenge is to have my files in sync prior to DST changes, an then perform one full copy afterwards.
As a workaround, I changed the time difference tolerance in the config file to 3602 seconds, which allows me to get my files synced.
Zenju, thank you very much for your work! The differences between FAT, NTFS and the interactions with DST are really a pain!
- Posts: 85
- Joined: 28 Aug 2012
> I changed the time difference tolerance in the config file to 3602 seconds
Does not work for me, the risk is too high that files got modified within an hour after their backup-snapshot.
I still favor the 1-hour option switch, despite its drawbacks.
Referring to the link that Zenju provided (very insightful, thanks):
> +-1h option: ..behaves incorrectly for all modes except "mirror"
Why would mirror be different from other modes? In all cases only "exact" differences (+-2s) are treated as an exception. Up to every user to run that risk when enabling the 1h-checkbox.
Does not work for me, the risk is too high that files got modified within an hour after their backup-snapshot.
I still favor the 1-hour option switch, despite its drawbacks.
Referring to the link that Zenju provided (very insightful, thanks):
> +-1h option: ..behaves incorrectly for all modes except "mirror"
Why would mirror be different from other modes? In all cases only "exact" differences (+-2s) are treated as an exception. Up to every user to run that risk when enabling the 1h-checkbox.
- Posts: 1
- Joined: 24 Jan 2014
Hi to everybody,
I have the same problem as Thommi, although I am running FFS v.6.3 under WinXP in FAT32.
Till some days ago FFS worked perfectly, and I could appreciate it even more when linked to Double Commander.
Now I tried to synchronize a directory on the hard disk with a previous copy of the same on a USB Key and FFS found lot of files to be refreshed. I gave a look to the help index about the daylight matter, did not go much into details, let it do and .. it stopped halfway for lack of space.
Forced to analyze what was going on, I reformatted the USB key (FAT32), copied the files on that and with a couple of different file managers I verified that the two directories were the same as file-size-date. But not for FFS which, as I could see, detects a 1 hour difference: the original files being newer than the copy (!).
To get a closer view to what is going on, I copied a smaller part of the original files (in C:) on another FAT32 HD directory(D:) and on the USB key as well (G:). Now it goes that FFS sees ALL the original files C: 1 hour newer than the copy in D: and in G:, but sees D: and G: equal.
Looking at my case in connection with that of Thommi, I suspect that FFS has got out of .. synchronism upon the recent daylight time change.
I am not so expert in SW to suggest a remedy, but I do hope that the authors can soon adjust such a very useful and nice program. Thanks
I have the same problem as Thommi, although I am running FFS v.6.3 under WinXP in FAT32.
Till some days ago FFS worked perfectly, and I could appreciate it even more when linked to Double Commander.
Now I tried to synchronize a directory on the hard disk with a previous copy of the same on a USB Key and FFS found lot of files to be refreshed. I gave a look to the help index about the daylight matter, did not go much into details, let it do and .. it stopped halfway for lack of space.
Forced to analyze what was going on, I reformatted the USB key (FAT32), copied the files on that and with a couple of different file managers I verified that the two directories were the same as file-size-date. But not for FFS which, as I could see, detects a 1 hour difference: the original files being newer than the copy (!).
To get a closer view to what is going on, I copied a smaller part of the original files (in C:) on another FAT32 HD directory(D:) and on the USB key as well (G:). Now it goes that FFS sees ALL the original files C: 1 hour newer than the copy in D: and in G:, but sees D: and G: equal.
Looking at my case in connection with that of Thommi, I suspect that FFS has got out of .. synchronism upon the recent daylight time change.
I am not so expert in SW to suggest a remedy, but I do hope that the authors can soon adjust such a very useful and nice program. Thanks
