FreeFileSync Forum

But you will never know if your backup data is not corrupted. You should at least compare by file content once in a while.
I see why you are happy. I used it this way for years, but at some point I took the next step to a proper backup solution (kopia/restic). I can recommend KopiaUI or Backrest if ...

That is exactly the reason I use euaie left/ right/ -t 2000 for my media collection...

Data corruption can occur with identical file size so relying on file size/time is not good enough:
https://en.wikipedia.org/wiki/Data_degradation#Mitigation

the easiest to use and the most reliable
I wouldn't go by how easy it is when it comes to important data. Most reliable compared to what ...

I tried to reproduce the error using a simple example with three folders, but it didn't work.
What did not work? The second task again or the reproduction?

I'll investigate further; perhaps I did something wrong with the exceptions.
Exceptions?

Could it be that copying from folders is one ...

Strange, it works for me. Are you sure that the files are modified on E and not K?
Try to reproduce it in different locations (can be any 3 folders for testing) and modify files at the source.

This is the command you need: https://rclone.org/commands/rclone_sync/

Which changes are not detected, on E or on M or both sides? What if you run task 2 first, then task 1?

Thank you!

This is a synchronization tool, not cp/rsync/rclone...

Sharing the solution could be helpful for others...

Try https://github.com/239/euaie, worked for me on exFAT.

src/888 is not a file so your question is confusing. What happens with src/888/124?

do you use include/exclude filters? you could also try rclone...

Just fork https://github.com/hkneptune/FreeFileSync and let us know about any meaningful contributions.

What about cases where it is done on purpose like exiftool -preserve?
You should not rely on file synchronization for data integrity or backups. Use the right tools with checksums.