[SOLVED] Fail to Copy Left Side Newer File to Right Side

[Radish]

OS = Windows 7 Pro. x64 SP1
FFS = 10.12, build: 12/05/2019 - Unicode x64
Sync Method = Mirror (Left Side --> Right Side)
File System = NTFS (for both the source and target drives)

Okay, I had this problem once before quite some time ago with the same file(s), so I do not think this is an issue with FFS 10.12. Now it's happening again and I would be grateful if someone could explain what is going on and maybe from there I can get a remedy.

(1) Before doing the Mirror sync I construct an MD5 checksums file so that I can check the sync went okay after the sync is completed.

(2a) I perform the sync and then check the result with the checksums file. The checksums reports everything is fine with the exception of one file titled WRITING PAD_copy001.tpd for which the right side has a different checksum than the left side (the already existing file on the right side having been put there on earlier Mirror syncs). On further investigation of this I find the following:

(2b) If I run the comparison using File Time and Size then FFS does not identify the file as different to the file that already exists on the right side. In this scenario FFS does not offer to copy the file left --> right.

(2c) If I test this again but this time using the File Content method as the comparison then FFS does identify the file on the left side as being different from the file on the right side, and, correctly, offers to copy left --> right.

Okay, so the file comparison done via different methods yields a different result as far as FFS is concerned. The following image shows the file properties for the left and right side files without letting FFS do a copy left --> right.

As you can see the file properties look identical except for the Access times (I don't understand what that is about and if that would have influence on the failure to copy when comparison File Time and Size is used).

Right, now if I try to manually copy the file on the left over to the right Windows reports the following:


So can someone explain why FFS fails to see the left side file as newer than the right side (when windows identifies it as such - and in doing so contradicts FFS finding when using the File Time and Size comparison method)?

(I hope I've explained all this clearly.)

[Zenju]

FFS is using a 2-seconds tolerance to handle sync with imprecise file systems like FAT: https://freefilesync.org/manual.php?topic=expert-settings
In the last screenshot the difference seems to be sub-second.

[Radish]

Okay, Zenju, thanks very much for the information. Couple of questions:

(1) What value would I have to enter in the XML to have FFS not use the 2 second tolerance setting (I'm guessing zero, myself but don't want to try it in case in ignorance I break something critical)? And/or would it be safe to just delete that line out of XML document?

(2) Would there be any issue/problem with disabling (maybe setting to zero) this setting for people not using FAT/FAT32 file systems.

In addition, would suggest that the Expert Settings page section FileTimeTolerance be edited/updated with notes on the above questions/issues.

[Zenju]

(1) What value would I have to enter in the XML to have FFS not use the 2 second tolerance setting

You could enter 0, but this wouldn't help in the above case since FFS is using seconds precision internally.

(2) Would there be any issue/problem with disabling (maybe setting to zero) this setting for people not using FAT/FAT32 file systems.

The problem is not so much local hard drives and memory sticks where you can be certain about the file system, but remote locations like network shares (who knows what's used internally) and also smart phones.

In addition, would suggest that the Expert Settings page section FileTimeTolerance be edited/updated with notes on the above questions/issues.

In general the above should mostly be a non-issue: For this situation to occur a file must be changed (a), synced (b) and changed again (c) with the delta between a) and c) being below 2 seconds.

[Radish]

You could enter 0, but this wouldn't help in the above case since FFS is using seconds precision internally.

In which case a strange thing is happening then. I changed the value to 0 and then started FFS and had it do a File Time and Size compare. It did identify the discrepancy and correctly offered to copy Left --> Right. I let it do that, did the sync and that was that. So something not working in the manner you suggest above -- seems FFS internally might be using sub-2-second timing (assuming I'm understanding what you're saying correctly). So for now I'll leave the value at 0.

In any case, I understand what the underlying issue is so I'll take this as 'solved' and won't fret too much about it in future. Very many thanks, Zenju.

[Zenju]

You could enter 0, but this wouldn't help in the above case since FFS is using seconds precision internally.

In which case a strange thing is happening then. I changed the value to 0 and then started FFS and had it do a File Time and Size compare. It did identify the discrepancy and correctly offered to copy Left --> Right.

I misinterpreted your last screenshot assuming that the two files had the same modification time in seconds (with a sub-second deviance). But the screenshot only shows minute resolution, so in reality the difference was probably 1 or 2 seconds, so with FileTimeTolerance = 0 FFS could detect this case.

[Radish]

Okay, thanks, Zenju.

[Radish]

I found this program FileTime and using that found the times to the second of the two files:

For the Left Side File:
Created: 19/9/2018 06:21:35 PM
Modified: 26/4/2019 06:33:54 PM
Last accessed: 19/9/2018 06:21:35 PM

For the Right Side File:
Created: 19/9/2018 06:21:35 PM
Modified: 26/4/2019 06:33:52 PM
Last accessed: 28/4/2019 09:03:42 AM

So the discrepancy was 2 seconds.