I change timezones quite frequently, recently by 1.25 hours. It is REALLY ANNOYING that FFS wants to to a full sync. Although I only backup 25GB of data, this is a pain. Particularly since I will be changing zone again (by 5.75 hours) in a few weeks. I work around this by resetting the time to the last sync location.
I and I am sure many others would be very grateful if you (Zenju) could incorporate an "ignore timezone changes" option in the otherwise six star program. Thanks
Change in Timezone
- Posts: 27
- Joined: 31 Jan 2010
-
- Posts: 2292
- Joined: 22 Aug 2012
You don't mention the file-system you are using for your data storage media.
If you use a file system that saves the timestamp in UTC (NTFS, EXT2/3/4/, ...),
you should not have any problem.
Conversely, if you use a file system in which the timestamp depends on the local
time-setting (like the still quite often used FAT16/32, particularly for USB sticks),
you can expect full-resync problems when changing time-zones.
See e.g.: http://ask-leo.com/why_do_file_timestamps_compare_differently_every_time_change.html
If possible, try switching the file system of your storage media to a UTC timestamp based one.
If that is not an option, you might consider setting the FFS maximum timestamp difference
to a value higher than your maximum time-zone changes. See the FFS help.
Equally named files at either end of equal size and a timestamp difference
smaller than the maximum timestamp difference will then be considered as "equal"
and will not be (re)synced.
I suppose (no personal experience) that equally named files at either end
of unequal size and a timestamp difference smaller than the specified maximum
timestamp difference constitutes a sync-conflict.
If you use a file system that saves the timestamp in UTC (NTFS, EXT2/3/4/, ...),
you should not have any problem.
Conversely, if you use a file system in which the timestamp depends on the local
time-setting (like the still quite often used FAT16/32, particularly for USB sticks),
you can expect full-resync problems when changing time-zones.
See e.g.: http://ask-leo.com/why_do_file_timestamps_compare_differently_every_time_change.html
If possible, try switching the file system of your storage media to a UTC timestamp based one.
If that is not an option, you might consider setting the FFS maximum timestamp difference
to a value higher than your maximum time-zone changes. See the FFS help.
Equally named files at either end of equal size and a timestamp difference
smaller than the maximum timestamp difference will then be considered as "equal"
and will not be (re)synced.
I suppose (no personal experience) that equally named files at either end
of unequal size and a timestamp difference smaller than the specified maximum
timestamp difference constitutes a sync-conflict.
- Posts: 8
- Joined: 3 Sep 2014
I would like to know as well:
* Does FFS use the full-hour differences as that (multiples of hours) or as maxima (as you specify). Because if when I specify 1 hour ignore, it is then going to always ignore anything SMALLER than 1 hour (which would be pointless for daylight savings differences) there will be a lot of annoyance if the program can no longer identify which file was most recently changed. Let me test this...
From testing it is clear that these are exact 1-hour intervals, not something half-way.
But this is just the strangest thing...
I'm perplexed at the moment.
My time is UTC+2 (DST +1) and I create two files. One is on NTFS and is modified at 8:17. The other is on FAT32 and is modified at 8:52. Before that, they were synced (by FFS). So the FAT32 one is modified last.
Fair enough, but in all circumstances, whatever I do, the 8:52 is taken as newer.
No I change the system clock to November 1, so my time is now UTC+1. I was expecting the NTFS time to be shown as different now. Since the file was stored with an UTC timestamp, Windows would either show it using the current DST (and it would become one hour less) or it would need to be adjusted according to the FILE's DST setting and Windows would show the original "local time". According to the article mentioned in the documentation for FFS, back in 2001, Windows would have shown the -1 hour offset date/time.
And, according to that article, Windows would have shown the FAT32 file as the exact same, since it would just output the (local) time that was saved with the file.
But presently, this is what happens:
1. My NTFS file is shown with the original local time.
2. My FAT32 file is shown with a PLUS 1 hour offset.
This file that was created on FAT32 with a mod time of 08:52 during UTC+2 (DST+1) and should therefore have UTC of 06:52 is now getting shown in Windows explorer as well as in FFS (I believe) with a time of 09:52, hence being UTC+3. If anything, it should get adjusted in the other direction. It is no longer an hour later. But relatively speaking, if the clock goes back one hour, everything that happened before would appear to have happened one hour later....??? But that is nonsense.
That is the reason for adjusting it in the OTHER direction in the first place. After putting the clock back one hour, the difference or distance between an earlier time seems 1 hour smaller. And you want to be able to perceive the distance between the now and events in the past, so you adjust the events in the past also by -1h. Then, the distance remains the same. Now, what Windows is doing to me, is that it says "This event in the past, it actually happened one hour later than you initially thought." Not only does the perceived distance become one hour smaller than it actually is, by increasing the time of the older event by one hour, they make it now a 2 hour lesser difference than what it really is....
Suddenly this event (the changed file) actually happened in the future, so to speak. I just adjusted my date to November 1, but the time remained the same. So now I've created this file in the future.
For what it's still worth... Supposing that Windows would actually work as intended, I can create a file on NTFS with a later mod time than on FAT32, then change DST, FAT32 jumps up one hour, and FFS still correctly identifies the NTFS file as newer....
Either it uses different information than what Explorer shows me... or it is really smart.
Then I let it sync, and the times are set identical. Then I change back to DST, and now Explorer shows the FAT32 file as older (-1h). Then I turn off the 1 hour ignore in FFS, and let it sync again. Now FFS wants to overwrite the NTFS file (that is shown as newer) with the FAT32 file (that is shown as older).
Alright, now I'm lost here. But, it gets even more interesting. Or strange. I let FFS do the sync, but it does not actually change the date of the file it supposedly overwrites. The NTFS file keeps getting shown as newer (which is actually the correct time) and the FAT32 file (that has an incorrect time) keeps getting shown as older, but FFS keeps wanting to redo the sync, ad infinitum.
Same thing happens when I copy manually. Same thing doesn't happen when I copy another file (from the FAT32 to the NTFS). FAT32 is not supposed to save any zone or DST information. How on earth can it cause the file to be copied to NTFS with a differently shown date?
Now I dismounted and remounted the FAT32 volume, and now it is copied as normally. But now it has the wrong time (on NTFS as well).
Weird stuff people. Maybe it was the result of an open file handle (on FAT32). No idea...
* Does FFS use the full-hour differences as that (multiples of hours) or as maxima (as you specify). Because if when I specify 1 hour ignore, it is then going to always ignore anything SMALLER than 1 hour (which would be pointless for daylight savings differences) there will be a lot of annoyance if the program can no longer identify which file was most recently changed. Let me test this...
From testing it is clear that these are exact 1-hour intervals, not something half-way.
But this is just the strangest thing...
I'm perplexed at the moment.
My time is UTC+2 (DST +1) and I create two files. One is on NTFS and is modified at 8:17. The other is on FAT32 and is modified at 8:52. Before that, they were synced (by FFS). So the FAT32 one is modified last.
Fair enough, but in all circumstances, whatever I do, the 8:52 is taken as newer.
No I change the system clock to November 1, so my time is now UTC+1. I was expecting the NTFS time to be shown as different now. Since the file was stored with an UTC timestamp, Windows would either show it using the current DST (and it would become one hour less) or it would need to be adjusted according to the FILE's DST setting and Windows would show the original "local time". According to the article mentioned in the documentation for FFS, back in 2001, Windows would have shown the -1 hour offset date/time.
And, according to that article, Windows would have shown the FAT32 file as the exact same, since it would just output the (local) time that was saved with the file.
But presently, this is what happens:
1. My NTFS file is shown with the original local time.
2. My FAT32 file is shown with a PLUS 1 hour offset.
This file that was created on FAT32 with a mod time of 08:52 during UTC+2 (DST+1) and should therefore have UTC of 06:52 is now getting shown in Windows explorer as well as in FFS (I believe) with a time of 09:52, hence being UTC+3. If anything, it should get adjusted in the other direction. It is no longer an hour later. But relatively speaking, if the clock goes back one hour, everything that happened before would appear to have happened one hour later....??? But that is nonsense.
That is the reason for adjusting it in the OTHER direction in the first place. After putting the clock back one hour, the difference or distance between an earlier time seems 1 hour smaller. And you want to be able to perceive the distance between the now and events in the past, so you adjust the events in the past also by -1h. Then, the distance remains the same. Now, what Windows is doing to me, is that it says "This event in the past, it actually happened one hour later than you initially thought." Not only does the perceived distance become one hour smaller than it actually is, by increasing the time of the older event by one hour, they make it now a 2 hour lesser difference than what it really is....
Suddenly this event (the changed file) actually happened in the future, so to speak. I just adjusted my date to November 1, but the time remained the same. So now I've created this file in the future.
For what it's still worth... Supposing that Windows would actually work as intended, I can create a file on NTFS with a later mod time than on FAT32, then change DST, FAT32 jumps up one hour, and FFS still correctly identifies the NTFS file as newer....
Either it uses different information than what Explorer shows me... or it is really smart.
Then I let it sync, and the times are set identical. Then I change back to DST, and now Explorer shows the FAT32 file as older (-1h). Then I turn off the 1 hour ignore in FFS, and let it sync again. Now FFS wants to overwrite the NTFS file (that is shown as newer) with the FAT32 file (that is shown as older).
Alright, now I'm lost here. But, it gets even more interesting. Or strange. I let FFS do the sync, but it does not actually change the date of the file it supposedly overwrites. The NTFS file keeps getting shown as newer (which is actually the correct time) and the FAT32 file (that has an incorrect time) keeps getting shown as older, but FFS keeps wanting to redo the sync, ad infinitum.
Same thing happens when I copy manually. Same thing doesn't happen when I copy another file (from the FAT32 to the NTFS). FAT32 is not supposed to save any zone or DST information. How on earth can it cause the file to be copied to NTFS with a differently shown date?
Now I dismounted and remounted the FAT32 volume, and now it is copied as normally. But now it has the wrong time (on NTFS as well).
Weird stuff people. Maybe it was the result of an open file handle (on FAT32). No idea...
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
> 1. My NTFS file is shown with the original local time.
> 2. My FAT32 file is shown with a PLUS 1 hour offset.
Windows changed its time calculations with Vista, so this specific part of the article is converse now: Instead of changing the local time on NTFS during a DST, now the local time of FAT is changed by +-1h when displayed in Explorer. This is just cosmetics and I guess the motivation for MS was to have stable times on NTFS to not have users lose trust in the correctness of their NTFS volumes, when they see the file times changing for no reason while FAT OTOH is legacy.
> FAT32 jumps up one hour, and FFS still correctly identifies the NTFS file as newer....
Did you see different file modifcation times in FreeFileSync than you saw in Windows Explorer? This would be a bug in case you're using FreeFileSync 6.9.
> FFS keeps wanting to redo the sync, ad infinitum.
This is caused by inconsistent buffering of Windows core routines (one may call it a bug, too). There are at least two Win32 functions that return different file modification times for the same file on FAT that was created as you described. However this is only a temporary problem and both functions will be in sync again after a system restart.
> 2. My FAT32 file is shown with a PLUS 1 hour offset.
Windows changed its time calculations with Vista, so this specific part of the article is converse now: Instead of changing the local time on NTFS during a DST, now the local time of FAT is changed by +-1h when displayed in Explorer. This is just cosmetics and I guess the motivation for MS was to have stable times on NTFS to not have users lose trust in the correctness of their NTFS volumes, when they see the file times changing for no reason while FAT OTOH is legacy.
> FAT32 jumps up one hour, and FFS still correctly identifies the NTFS file as newer....
Did you see different file modifcation times in FreeFileSync than you saw in Windows Explorer? This would be a bug in case you're using FreeFileSync 6.9.
> FFS keeps wanting to redo the sync, ad infinitum.
This is caused by inconsistent buffering of Windows core routines (one may call it a bug, too). There are at least two Win32 functions that return different file modification times for the same file on FAT that was created as you described. However this is only a temporary problem and both functions will be in sync again after a system restart.
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
With the latest changes removing the old "daylight saving time hack", it's not possible to handle different time shifts at the same time anymore. OTOH I'm not sure how much of the FreeFileSync user base really needs support for time zones - your feedback is the only one so far. Therefore until further the recommendation is to let go of FAT and use NTFS even for portable devices like USB sticks. This avoids all time zone and daylight saving time-related issues in first place by properly storing times in UTC format.I change timezones quite frequently, recently by 1.25 hours. It is REALLY ANNOYING that FFS wants to to a full sync. Although I only backup 25GB of data, this is a pain. Particularly since I will be changing zone again (by 5.75 hours) in a few weeks. I work around this by resetting the time to the last sync location.
I and I am sure many others would be very grateful if you (Zenju) could incorporate an "ignore timezone changes" option in the otherwise six star program. Thanksjonrichco
- Posts: 2
- Joined: 18 Nov 2021
It's an old thread, but that's the first result I got from a search. I'm facing the same problem with a USB stick formatted with FAT32 (and it was made in 2020!). I just read however that the newer standard, exFAT, adds a time zone marker with the timestamps. I'm certainly going to try reformatting my USB stick to exFAT, since it's more appropriate than NTFS for a removable stick.
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
Last time I checked exFAT behaved the same as FAT32 with regards to not storing UTC time. So the current advice is to ignore time-zone offsets: https://freefilesync.org/manual.php?topic=daylight-saving-time
- Posts: 2
- Joined: 18 Nov 2021
Thanks for the info on exFAT, that saves me time. I'd seen the timezone offset option discussed in this thread, but didn't like it because I thought I risked missing changes made within 1 hour. I see I was mistaken, since the manual says "the time shift setting should not be confused with a time interval or tolerance".
