Mirror synchronizing into same destination

[meATffsForum]

Minimal example:
2 folder pairs
1. d:\source1 d:\destination
2. d:\source2 d:\destination
Both source directories contain one distinct file respectively.

What would I expect?
Execution of 1st folder pair would make destination like source1.
Delete everything on destination, add file from source1.
Then
Execution of 2nd folder pair would make destination like source2.
Delete everything on destination, add file from source2.
So the resulting destination would be the mirror synchronization
of the last synchronization pair (2nd).
(If there would be a consistence check it should warn me about that.)

But what happens?
Clicking Compare, FFS signals it will copy both files.
And that's what I does when executing mirror.

This seems terrible wrong to me; can please someone explain?

BTW
Even more strange:
If after doing the above executing a mirror synchronize again,
FFS does exactly the way I would expect:
Execute the folder pairs consecutively (and by that deleting
both files on destination again)!!
However this time there pops the notice (I would have exptected
at in the first example too).

[Plerry]

Unless you disabled that, FFS already warned you that there is an overlap between one or more of your sync locations.

What is happening:
When you run your FFS Compare, FFS determines the required sync actions.
For the initial case, d:\destination is empty, so for your source1 pair it proposes to copy the content of your source1 and of your source2 to d:\destination.
Compare is not aware of / does not take into account the post-sync status, so the proposed actions are correct.
For the consecutive sync, Compare notices that there exists a (sync2)file in d:\destination that does not exist in source1 and proposes to delete it, similarly it notices that there exists a (sync1)file in d:\destination that does not exist in source2 and proposes to delete it. So after the sync d:\destination will be empty again.

You should essentially always avoid an overlap in sync locations, either by using different locations, or by using appropriate In- and/or Exclude Filter rules.
To "solve" your use-case, you could
• Mirror sync each left-right pair to different destinations, e.g.
1. d:\source1 => d:\destination1
2. d:\source2 => d:\destination2
• Mirror sync your existing left-right pairs, but use a local Include Filter rule per pair (via the funnel-icon mid between each pair), including the specific source1 file for pair1 and the specific source2 file for pair2.
• Mirror sync your existing left-right pairs, but use a local Exclude Filter rule per pair, excluding the specific source2 file for pair1 and the specific source1 file for pair2.

or perhaps the simplest solution
• Using your existing left-right pairs, and use the Update sync variant instead of the Mirror sync variant.

[meATffsForum]

Thank you for your reply.
However you're wrong:

Unless you disabled that, FFS already warned you that there is an overlap between one or more of your sync locations.

I din't disable the warning, but FFS didn't warn me (at 1st syncing).
That's what I wrote already in section "What would I expect".

Compare is not aware of / does not take into account the post-sync sync status...

Yes looks like.
And this seems wrong to me.

First FFS warns about the overlapping (I DOES NOT for me),
and then it doesn't do what it warns for
(the effect of syncing second pair = deleting files from first sync)
but does something strange (executing the sync pair mirroring
at a basis of Compare start time; and not of time of executing
the folder pair line). Result is something like a mirror/ update mix.

Executing Compare/ Synchronize a 2nd time is as expected (including warning).

You're getting me wrong.
I DO NOT ask for help.
I pointing to an error in FFS.
That's why I choose the minimal example.

In other words:
For any (consistency!) sequence of sync ops, it should hold: SEQ = SEQ^n
I.e. from 2nd syncing on there should be no action anymore.
(In my (most simple) case there is: SEQ = SEQ^(2n); due to the inconsistency.
And every odd step SEQ execution results in a wrong destination.)

Summary:
1st error: FFS doesn't warn me of the inconsistency.
2nd error: FFS takes the time of starting the job as basis (but should take the
actual time of execution of each line.

Sorry, but I won't discuss that any further.
Let a dev take it, or leave it.
It is a constructive feedback to errors of FFS (See "Vision").

[meATffsForum]

Typo in:

... (In my (most simple) case there is: SEQ = SEQ^(2n)

Correct:
SEQ^(2)=id

[Gianni1962]

Hi Plerry,

I did a test exactly as suggested by meATffsForum.

Configuration:
Two folder pairs
d:\source1 d:\destination
d:\source2 d:\destination
Mirror variant
Don't use database
Permanent

d:\source1 contains file1.txt
d:\source2 contains file2.txt
d:\destination is empty

At the first Compare and Synchronize I didn't receive any warning and in d:\destination I find the two files coming from d:\source1 and d:\source2

At the second Compare I didn't receive any warning, I receive it only when Synchronize is confirmed, and the message is very cryptic:

Screenshot 2025-07-06 141839.png (17.37 KiB) Viewed 513 times

From the log file:

Some files will be synchronized as part of multiple folder pairs.
To avoid conflicts, set up exclude filters so that each updated file is included by only one folder pair.

D:\destination 👓 file1.txt
D:\destination 💾 file1.txt

D:\destination 💾 file2.txt
D:\destination 👓 file2.txt

💾: Write access 👓: Read access

Pressing Ignore results in both files being deleted from d:\destination

[Gianni1962]

Important information that I forgot to provide in the first place:

Operating System: Windows 11 Pro 24H2
FreeFileSync Version: 14.3 (Donation Edition)

PS: I would have added them to the original post but it was no longer editable.

[Plerry]

@Gianni1962
I can confirm your test results: no warning when running the 1st/3rd/5th etc sync; only a warning on the 2nd/4th/6th etc sync when FFS intends to delete file1.txt and file2.txt.
Not what I expected, and not what it should be (in my opinion).

Nevertheless, this use case (where there is a full or partial overlap between one or more sync locations) is to be avoided at all times, as it can (and oftentimes does give) unexpected/unintended sync results. And in the described case, you receive the warning at least when you run the risk of loosing the data.
And I agree the description in the warning is rather cryptic. But I am not sure that a description along the line of "there is a full or partial overlap between one or more sync locations" would be considered less cryptic.

As the TS meATffsForum won't discuss it any further, I refrain from reacting to his/her reply to my answer to his/her initial posting.

[Zenju]

Works as designed. During the first sync there is no conflict. During the second sync there are two conflicts that FFS warns about.

[meATffsForum]

Works as designed.

Well... then the design is bad in that matter.

May I ask you to have a look at the posts from users above?

[kriebie]

Works as designed. During the first sync there is no conflict. During the second sync there are two conflicts that FFS warns about.

Strictly taken that may technically be correct, but 'Ignore' seems to be open for interpretations. I can see the conflict there. I would also be intuitively inclined to think that 'Ignore' means 'Ignore the existence of these files' or 'Skip these files', rather than triggering a sequence where they are inadvertently deleted in all folders.
Perhaps better to label this button 'Proceed' or 'Proceed anyway'.
Or perhaps not even give the option and demand that the conflicts are resolved. Because that is the situation you have: conflicts.

[Plerry]

... Sorry, but I won't discuss that any further. ...

And yet here you are, criticizing Zenju, while the real problem is your own, faulty choice of folder pairs, about which I already wrote

Nevertheless, this use case (where there is a full or partial overlap between one or more sync locations) is to be avoided at all times, as it can (and oftentimes does give) unexpected/unintended sync results. And in the described case, you receive the warning at least when you run the risk of loosing the data.

[meATffsForum]

If course it's "my fault" - never denied that.

I (and obviously not only me) wanted to point that it would be a desireable behaviour of FFS
if it would point me if entering bad values.
Tha's what a good app does - especially if it's at such important matter as syncing is.

@Plerry:
I get the impression you take it as a kind of blashpemie if someone give hints for improvement.
Well - just for you - I REALLY LOVE FFS :)

[xCSxXenon]

As kriebie said, 'ignore' is certainly interpretation. Ignoring a warning and ignoring the files both make sense to me. "Proceed anyway" makes way more sense for the current behavior. Adding "Exclude conflicts" would also be super awesome to have. This let's you get the good data processed and let's you fix the issue(s) after.

I can agree the error could be described better. I never loved the icons, but I never really had a better suggestion. It should probably include something more descriptive, such as:
Conflict: "file1.txt" in location "D:\destination\" is marked equal in [folder pair x] but slated for [update | deleteion] by [folder pair y]

Semi-related, this could also be expanded for other conflicts:
Conflict: "filexyz.txt" in locations "C:\mydir\" and "D:\backup\mydir\" have both been updated since last sync. Please resolve by selecting which side to keep in the FFS comparison overview.
Maybe a fever dream, but being able to go through them in the panel directly would be great also. Something like some buttons that offer "Keep left", "Keep right", "Exclude file(s)", etc.

Of course, the solution is to fix the locations specified, or the sync method. Nonetheless, the warning exists because sometimes mistakes do happen. A trip to the forum typically corrects the root issue, but I believe a solution, or the wording, similar to what I provided would help most of those users figure it out without wasting their time, our time, and whatever time is lost waiting for a reply.