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

[k8962c]

Sorry to resurect and old post, but I'd like to 2nd this request for some kind of flag or option for the described scenario.
I recently had a case where it wanted to update files with older timestamped copies. In my normal usecase this is never intentional.
I think for most users this would never be intentional, so having an option in the Sync settings to flag up a warning in this case would be useful to warn against accidental data loss.
If you sometimes intentionally overwrite older files, you will know the warning is correct etc.
If you do it often, then don't check the flag for this warning.

Also, when reviewing the suggested actions, it indicated "left side is newer", showing the timestampes, and then indicated the action was "updating left side", which makes no sense.
If the sync is driven by changes, not timestamps, then it should say which side is a newer update? I assume the dates/times shown are all file timestamps, not filesystem update-times which I assume FFS doesn't have access to?

(My usecase I use Dropbox to sync files between a local and remote office PC, then use FFS on the remote office PC to sync to the server. Dropbox can occasionally therefore 'update' the files without the timestamp actually being different, which I believe led to this issue. (Syncing direct over VPN is very slow for multiple files & GBs of data.))

[xCSxXenon]

I'm betting if you disable using a database, it will work as you are describing.
I don't think anything should change, as I expect 'two-way' syncing to propagate any change from the changed side to the other. Modifying it to always keep the newer file is no longer a 'two-way' sync

[k8962c]

I'm not suggesting to modify the behaviour at all, simply to flag up a warning if the standard change propogation two-way sync will result in an older file being overwritten by a newer one by timestamp.
I still need to have the database enabled (otherwise it won't cope with propogating file deletion) so the two-way sync is still what I want, propogating changes, but in the weird cases where this results in newer files being overwritten, I want to know this so I can review and confirm it's doing what I want.

[vqvq]

I'm not suggesting to modify the behaviour at all, simply to flag up a warning if the standard change propogation two-way sync will result in an older file being overwritten by a newer one by timestamp.

Hi, that's exactly what I hoped for, thanks.
As it is, I still use FFS but with extreme caution. Clearly, for large number of files, it is really difficult/impossible to manually check and find the erroneous/unwanted/destructive copy direction.
I really can't understand why such a simple and cosmetic change which does not affect the overall program logic and functionality can not be applied.

[k8962c]

I realise its open source so I could have a crack at adding this; I believe there's similar functionality for "the folders look significantly different" warning, although not sure if this just shows as a warning during the sync or has a popup before, it's been a while since I've seen that one?

[vqvq]

I realise its open source so I could have a crack at adding this

Having bought the Business Edition recently I would hope such proposals to improve FFS could be at least considered by the authors.
Anyway, going the open source path is an interesting idea, though I definitely have no time for this.
Thanks