What file timestamp precision does FreeFileSync use?

[ocean]

Hi
I noticed that even when I set FileTimeTolerance to 0, FreeFileSync still treats files with timestamp differences between 2ms to 77ms as identical.

After setting FileTimeTolerance to 0, I did notice more files being detected as different compared to the default setting. But such small timestamp differences between 2ms to 77ms are still treated as identical.

I would like to know:
What is the actual timestamp precision that FreeFileSync uses?
Is this behavior by design?
Thank you.

--------------

Version: FreeFileSync 14.0
System: Windows 10 22H2
Both drives are NTFS (Internal SSD)

[ocean]

I haven't tested more files, but I guess files with time differences under 100ms or 1000ms would be considered equal.

[xCSxXenon]

Similar thread, unresolved?
viewtopic.php?t=8900
I posted there that timestamps were only causing a difference to be detected if they were a minute apart

[Zenju]

What is the actual timestamp precision that FreeFileSync uses?

1 second, rounded down.

[ocean]

It would be nice to have an option to disable round down. I use FFS to sync millions of files, and some files have problems with this.

[therube]

Could you explain in what situations you're impacted by this, where this 2..77ms matters?


(A different, elsewhere, timestamp precision issue, Date-modifieddupe: or similar, but ignore x amount of time.)

[ocean]

I'll need to look into this more, but honestly I'm scratching my head about why FreeFileSync needs to round down at all. Isn't that what FileTimeTolerance is for?

[Zenju]

"FileTimeTolerance" is a remnant from the beginning of the software when I thought having it configurable was a good idea.

Meanwhile I think it doesn't make sense to have this options set to anything other than 2 seconds, as long as the FAT format is still in general use. Also, higher precision creates additional problems and solves nothing.

[ocean]

I figured out the issue:

When batch editing files (like using VSCode's Ctrl+Shift+F), each file will have only a few milliseconds difference in timestamps.

If I overwrite files with such tiny timestamp differences, and the file size hasn't changed (for example, changing "Attribute = 0" to "Attribute = 1"), then it will be consider as equal.

[ocean]

Personally, I feel the default behavior should be FileTimeTolerance = 0 with no round down.

Although FAT is widely used, I wonder how many people actually use FFS for USB drives formatted in FAT rather than simple copy-paste. I personally only use FFS on my PC or external SSD and turn on version control.

It doesn't make sense to lower precision by default just for FAT compatibility. Users should decide for themselves whether to enable FileTimeTolerance = 2, or use formats with better precision like exFAT or NTFS. Setting FileTimeTolerance = 2 doesn't fix FAT's precision limitations. Instead, it hides the problem.
If FileTimeTolerance = 2 is set as default, users might not understand FAT's precision issues until they discover problems the hard way.