as per the log file, rclone did exclude from the sync 2021/05/30 19:03:51 DEBUG : leaderboardsconfig.txt: Excluded 2021/05/30 19:03:51 DEBUG : leaderboardsconfig.txt: Excluded
So I do not understand correctly synchronization:
If I copied initially without a filter, then I added some values to the filter, then these values will not be deleted?
Happy to try to help. But I am also not exactly sure what you mean by "mirror sync". I think of "mirror" as one-way (which rclone does). rclone does not (yet) do two-way sync.
That means that rclone will make the first remote look like the second but not the other way around. If you modify a file on the second, it could get overwritten by the first depending on flags and settings.
rclone only does this for now but there is PR 5164 where bi-directional sync is implemented based on rclonesync-v2.
rclonesync-v2 is a Python tool that wraps rclone and does bi-directional syncing. There is nothing wrong with it per se, but bi-directional syncing is way more opinionated than one-way. (See the aforementioned PR for a discussion about this). I preferred things done my way (both in behavior details and the underlying algorithm) so I wrote my own syncrclone. Actually, that was the third bi-directional sync tool I wrote. I also wrote PyFiSync which can support rclone remote only. The latter is better if you can run Python and rsync (not rclone) on the remote since PyFiSync goes out of its way to track moves with modification and takes advantage of rsync's ability to sync minor differences within files. syncrclone is better for rclone. (The first sync tool I wrote is long deprecated that it's barely worth mentioning).
So if you want bi-directional sync, check out either syncrclone or rclonesync-v2. Or wait to see if it makes it into rclone (in which case, I may move to it or stick with my tool since I prefer it). And if you want more detail and discussion, check out the PR