New Dangerous bug? FreeFileSync showing opposite direction of copying

[vqvq]

Hi,
I have updated to v.11.12 today. I regularly sync my work D: drive with a USB drive.
Now, after Compare, FreeFileSync indicates it will update the NEWER existing files on my USB with their OLDER versions from my hard drive. I seem to have done this earlier today on my office PC and notebook. Only now, on my home PC I noticed the problem. So I will need to recheck all the mess created with the wrong syncing.
Is there any explanation for this, apart from being a (new?) bug? It has potentially disastrous consequences..
Note: The time difference is not mere hours etc., it is several days typically - e.g. it plans to overwrite a xls file dated 23.6.2021 with an old version dated 5.12.2020 !!! Quite scary...
Any ideas? Thanks
Vaclav

[lesm]

Another one can confirm this. I was ready to update, but...

[therube]

What Comparison & Sync settings are you using?

[vqvq]

Hi,
I don't know what specific setting would be of interest, so just a brief description:
- Select a variant: File time and size
- Ignore timeshift not filled in
- Filter - Some folders and file types excluded, hardly to do with this error?
- Synchronization: 2-way
I found I'm in BIG trouble now, having to reconstruct a lot of files/folders on my office PC and laptop from the mess created by yesterday 'synchronization' using FFS. Unbelievable, very frustrating indeed

[xCSxXenon]

What reason does FFS give for wanting to sync the items? If you hover over the middle where it shows the icon referring to the action it wants to take, it tells you why it wants to do that. I updated and do not have this issue

[vqvq]

I can't paste a printscreen here, so a textual description only:
- hover over the icon, I get CORRECT text "Right side is newer <-22.09.2017 10:31:02 -> 13.07.2021 16:50:06"
However, the icon showing planned action is the green arrow POINTING TO THE RIGHT, thus indicating that the left file is to be copied to the right panel, which is, the opposite of what should happen.

I took the screenshots, you can view them here with my comments:
https://drive.google.com/file/d/1ihpy4DOUpwHJdrP_-vaeIQKpM4z8-uuL/view?usp=sharing

Any suggestions welcome. However, too late for me, having thousands files messed up. Beware

[xCSxXenon]

Interesting...
Can you screenshot your sync settings as well?

[vqvq]

yes, it's here
https://drive.google.com/file/d/1ChQBlhrWznAL2xsgLKzV9i-tMsN8Upei/view?usp=sharing

I have uninstalled FFS, installed v.11.5 and it shows correct direction of copying. Damned update...

[xCSxXenon]

I wouldn't fault the update when you are the only one with the issue so far. What version does it break if you update one-by-one?

[vqvq]

OK, maybe just for me, but the update to 11.12 was a total disaster. I have restored most (all?) of my rewritten files from backups, but it was really unpleasant experience.

I tested some older FFS versions. But it was done after my restore, so the original state of files on disk is different now. v.11.5, 11.10 - OK

Now, to increase confusion - I tried again 11.12 and it seems OK - at least on my current disk status I can not repeat the previous error. I use still the same sync setting, no change here. So, it is very strange and finding the source of the bug is not easy.

Note: The compare task is quite big, having ~300.000 files and ~300+GB data. My unfortunate erroneous sync was done after a longer period so I had several thousands files marked for syncing. I suspect that might have something to do with the problem (some memory overflow possibly?)? Anyway, I can NOT reproduce the error now. But after the described experience, I'm rather hesitant regarding my trust in FFS. Let's hope the error does not reappear again.

[Zenju]

There's a misconception regarding how the "two way sync variant" works. It does NOT work by overwriting old files by newer ones. Instead it propagates any change. Only for the first sync, when no sync.ffs_db file exists yet, the fallback algorithm is to overwrite old with newer files. https://freefilesync.org/manual.php?topic=synchronization-settings

[vqvq]

OK, but what is the logic of such propagation?
I'm struggling to see a reasonable explanation for the situation shown in my screenshots:
https://drive.google.com/file/d/1ChQBlhrWznAL2xsgLKzV9i-tMsN8Upei/view
How can this happen?
In my case described above, the 'propagation' had major destructive effects.
How can one avoid that?

[Zenju]

https://drive.google.com/file/d/1ChQBlhrWznAL2xsgLKzV9i-tMsN8Upei/view
How can this happen?

On the left side, e.g. Loziska.xls, the 2021 version of the file was replaced by the 2017 version outside of FreeFileSync since the last sync. FFS then sees this change, and propagates it to the other side, right in this case.

[Zenju]

In my case described above, the 'propagation' had major destructive effects.
How can one avoid that?

Use versioning: https://freefilesync.org/manual.php?topic=versioning

[vqvq]

Regarding the explanation - well, I try to believe this explanation.
Although, I don't believe that I could somehow replace my many newer files with older versions myself ('outside of FFS') - I'm pretty sure this was not the case.

Proposal: Could there be a warning added such that in case the 2-way sync results in overwriting files with version having older timestamp, some alert is shown? At least a red (instead of green) arrow showing the direction to indicate 'something is strange/unusual'? That would not change the overall program logic at all while helping users avoid data loss similar to what I have experienced.

Re: Versioning - thanks for advice, I will look at this

[Zenju]

Proposal: Could there be a warning added such that in case the 2-way sync results in overwriting files with version having older timestamp, some alert is shown? At least a red (instead of green) arrow showing the direction to indicate 'something is strange/unusual'? That would not change the overall program logic at all while helping users avoid data loss similar to what I have experienced.

This would be a half-measure at best, annoying in the ordinary case at worst. If you deliberately revert some files to an older state, you'll generally want this change propagated as well. If on the other hand this happened by accident, e.g. Windows crashed, and automatically resets the system to a previous restore point, including some of your project files (experienced this unfortunate event myself...), then this is just a specific case of data corruption in general, which a backup tool has no tools to detect. The only real protection against this kind of problem seems versioning.

[vqvq]

I'm not talking about a scenario after Windows crash or similar disaster - nothing of that sort happened on any of my 3 computers but I still lost my data.

This would just be a half-measure at best

I agree, but surely better to increase the chance for the user to notice that something potentially wrong is going to happen. Half-measure being much better than nothing.

... annoying in the ordinary case at worst

I don't share that opinion. Rewriting newer files with their older version is hardly an ordinary case, or is it? Having just a small visual reminder of this situation by a different color of the indication arrow is hardly annoying at all. Definitely far less annoying than having the newer files overwritten by accident.

This proposal is a trivial modification of the software. If you consider it to be "annoying in the ordinary case", it could be easily offered as an option only so those annoyed by that would avoid this. The rest might be very lucky to have that warning. Please, reconsider. Thanks