Mirroring bug (?) related to FileTimeTolerance

[guarster]

I have set FileTimeTolerance to 0 and recently I discovered a strange behavior.

I use the "Mirror" variant with a database file. I have two files with 1 second difference in their modification date, but otherwise identical. When I try to sync, a message appears about these two files, saying "Cannot determine sync-direction: No change since last synchronization".

I have read this post: viewtopic.php?t=1183&sid=e6fd545dc346bd8f359392ae2df8222d
and while I understand Zenju's explanation and that FFS can't be sure which file is newer,
I'd still expect the program to just copy the file from the left to the right, since I have selected the "Mirror" variant.

Since FFS knows that the files differ, why does it matter which is newer, when I have chosen to always copy from left to right?

[guarster]

According to my settings, the direction of the sync should always be from left to right.

[Plerry]

Your problem may be self-inflicted.
> I have set FileTimeTolerance to 0 ...
The simplest way to "fix" your problem is to change it back to the default setting of 2 seconds, as apparently even required for FAT/FAT32 file systems.

The "Cannot determine sync-direction: No change since last synchronization" is probably the result of the since FFS version 13.x default use of the database. See e.g. here.
Disabling the use of the database will probably seemingly solve your user problem, but with your FileTimeTolerance set to 0 may result in repetitive unnecessary recopying.

But I agree with your more fundamental statement.
If FFS deems files to be different in any relevant aspect, in a Mirror (and Update) sync variant it should simply update the target-side file to match the source-side file.

[Plerry]

Further to my last remark just above:
As per the earlier description by Zenju (the author of FFS), your "Cannot determine sync-direction: No change since last synchronization" conflict is apparently considered to be of the 2nd category.

[Zenju]

Your problem may be self-inflicted.
> I have set FileTimeTolerance to 0 ...

I tend to agree with Plerry here. The reason you're seeing a 1 second file time difference is (most likely) because the underlying file system is lacking precision.

viewtopic.php?t=1183#p5178 was an interesting read from 11 years back. Meanwhile I come to a different conclusion and would apply file time tolerance also when comparing DB entries with the current state. Whether this makes sense is a different question(*), but it's what the user has requested. I've fixed this for the next version, which will get rid of "Cannot determine sync-direction: No change since last synchronization":
https://www.mediafire.com/file/qppuo2eureyj58y/FreeFileSync_13.5_%255BBeta%255D_Windows_Setup%25283%2529.exe

*) As long as there is FAT(32) there is no reason to have a file time tolerance other than "2". In the far future when FAT is finally gone, there will be a glorious moment when file time tolerance can finally be set to "0". However, probably not in this century anymore!

[exscape]

I'm having this issue as well, but I have not changed FileTimeTolerance, and have verified that it's set to 2.
I'm syncing from NTFS to a Samba share (on a ZFSOnLinux backend).

However, the issue have so far only occurred one one set of files, Slay the Spire 2 run history files. So there's something going on there. It's happened several times, even when I choose to overwrite.
When I look at the file times, they always seem to be 3 seconds more recent on the mirror destination, which doesn't make sense.

What I also don't understand is why there's an issue to begin with. If it can tell that the files are unchanged, why not either let them be, or update the times on the destination? Or if it can't tell, why not copy them over and make sure?

Not being able to determine sync direction when set to "Mirror" doesn't seem right. There's only one choice available.

[xCSxXenon]

What does the comparison results look like for those files?

[exscape]

What does the comparison results look like for those files?

Same size, and those 3 seconds of difference. As far as I can tell, always exactly 3 seconds, but I didn't verify for literally every file.



I assume I could work around this by increasing the FileTimeTolerance to 3 or maybe 4 seconds, but I'm not sure why this happens to begin with.

The destination directory is only ever written to by FreeFileSync.

[therube]

Have you verified that the files are identical - that they differ only by date, between C: & F:?

If you copy (Update or whatever) the same source files to another destination, not on 'Samba share (on a ZFSOnLinux backend)', do the files end up identical & also dated the same?

[exscape]

Have you verified that the files are identical - that they differ only by date, between C: & F:?

Yes, every file has same md5sum on both sides.

If you copy (Update or whatever) the same source files to another destination, not on 'Samba share (on a ZFSOnLinux backend)', do the files end up identical & also dated the same?

Do you mean with FreeFileSync? I tried this to a local SSD (NTFS), and yes, source and destination end up with the same times (and content).

Edit: But the same is true for 99.9% of the files copied to the Samba share, too. Only these StS 2 run files cause issues for some reason.
Of course, the root cause could be that the game for whatever reason changes the modification times of the files, but I still think FreeFileSync showing this dialog on every sync is a bug. It's doubly annoying that there's no way to simply tell it to copy them over without clicking "Switch", which takes several minutes, as it re-scans about 2 million files.

[xCSxXenon]

FFS is warning you because you are using a database to track changes. This adds the ability to detect this conflict, which is good, because then FFS would sync those files every single time you run it, even if they didn't change. Are these the only .run files in your dataset? Something on the network share side is likely causing this