I've done some tests and it seems that if the modified date between two files of the same length is 2 seconds or less then the files are considered the same. Is this correct?
I ask because when backing up files from my SSD to an external exFAT drive, for some weird reason the modified date on most of the files is altered by a second or two eg. the original file has a modified date of, 16 November 2021, 16:02:23, the copied file has a modified date of 16 November 2021, 16:02:25. However they seem to have the same time stamp according to FreeFileSync.
This phenomenon also happens with a simple drag and drop copy from Windows explorer between drives.
Window of time between files to be considered equal
- Posts: 3
- Joined: 16 Nov 2021
-
- Posts: 4059
- Joined: 11 Jun 2019
I can confirm the same behavior with two folders on my desktop and txt files with four characters each. They will only be detected as different once the minute has changed. Not sure if this is a Windows limitation or FFS, or whether it matters at all. Most files that would change that often are likely garbage, or if they aren't, will be detected as a change in 60 seconds or less. Super edge case
- Posts: 3
- Joined: 16 Nov 2021
OK thank you, so I downloaded the source code and found a couple of lines of code with comments:
The article describes the strange behaviour of time-stamps rounding UP to the next exact 2 second interval when copying to FAT-formatted drives. It does fail to explain why though, except the fact that FAT was invented back in 1977.
//max. allowed file time deviation; < 0 means unlimited tolerance; default 2s: FAT vs NTFS
int fileTimeTolerance = zen::FAT_FILE_TIME_PRECISION_SEC;
...
const int FAT_FILE_TIME_PRECISION_SEC = 2; //https://devblogs.microsoft.com/oldnewthing/?p=83
-
- Posts: 71
- Joined: 22 May 2006
...it's a FAT "feature"...
https://freefilesync.org/manual.php?topic=expert-settings
FileTimeTolerance:
By default file modification times are allowed to have a 2 second difference while still being considered equal. This is required by FAT/FAT32 file systems which store file times only with a 2-second precision.
There are many topic about this...
search.php?keywords=FileTimeTolerance
https://freefilesync.org/manual.php?topic=expert-settings
FileTimeTolerance:
By default file modification times are allowed to have a 2 second difference while still being considered equal. This is required by FAT/FAT32 file systems which store file times only with a 2-second precision.
There are many topic about this...
search.php?keywords=FileTimeTolerance
-
- Posts: 4059
- Joined: 11 Jun 2019
My test was on my NTFS OS volume
- Posts: 1038
- Joined: 8 May 2006
That wouldn't seem right.My test was on my NTFS OS volume ... I can confirm the same behavior with two folders on my desktop and txt files with four characters each.
Do they have to be .txt?
Is it the file name that is 4 chars (long), or the file has 4 chars within it (4 bytes)?
If you change the extension from .txt to .zip, does the same happen?
Are you sure you didn't "touch" the second file's date/time (if you manually added 4 chars to [within] the file - rather then copying the file)?
-
- Posts: 4059
- Joined: 11 Jun 2019
Test it on yours
I only tested with txt, because is experienced the claimed behavior.
They were files with the same name, they have to be. They each had four characters in them, different characters of course. I simply opened them both, added four characters, saved the first one, then saved the second a few seconds after. FFS then detected that there was nothing to sync. The timestamps showed they were seconds apart in modification time.
I only tested with txt, because is experienced the claimed behavior.
They were files with the same name, they have to be. They each had four characters in them, different characters of course. I simply opened them both, added four characters, saved the first one, then saved the second a few seconds after. FFS then detected that there was nothing to sync. The timestamps showed they were seconds apart in modification time.
- Posts: 1038
- Joined: 8 May 2006
> Test it on yours
Already had (Win7) & unable to confirm.
> files with the same name
> They each had four characters in them
Right. Time & size comparison.
> different characters of course
That shouldn't matter (i.e., contents could be the same), unless you were doing a Content comparison.
> timestamps showed they were seconds apart in modification time
How many seconds matters. +/- 2 seconds should compare equally.
Outside of that, they differ (to FFS).
Update sync, left to right, compare on time & size:
out4.txt. left is 2:01:00, right varies; 2:00:57 ... 2:01:03
1. right is older, 3 seconds, so will be updated
2. right is "not older", only 2 seconds, so considered as equal
3. right is "newer", only 1 second, again considered equal
4. right is newer, 3 seconds, right is newer then left, so default action is to not update older over newer, so won't be updated
.
(right-click, View image, to see it larger)
Already had (Win7) & unable to confirm.
> files with the same name
> They each had four characters in them
Right. Time & size comparison.
> different characters of course
That shouldn't matter (i.e., contents could be the same), unless you were doing a Content comparison.
> timestamps showed they were seconds apart in modification time
How many seconds matters. +/- 2 seconds should compare equally.
Outside of that, they differ (to FFS).
Update sync, left to right, compare on time & size:
out4.txt. left is 2:01:00, right varies; 2:00:57 ... 2:01:03
1. right is older, 3 seconds, so will be updated
2. right is "not older", only 2 seconds, so considered as equal
3. right is "newer", only 1 second, again considered equal
4. right is newer, 3 seconds, right is newer then left, so default action is to not update older over newer, so won't be updated
.
- FreeFileSync Update sync Time diffs.png (13.03 KiB) Viewed 547 times
