Inaccurate warning: multiple base folders

[ladarrius]

There appears to be an inaccurate warning being generated:

[0:00:00 PM]  Warning:  Some files will be synchronized as part of multiple base folders.
                        To avoid conflicts, set up exclude filters so that each updated file is included by only one base folder.
                        C:\test\to


a minimal example and sample log file:

BatchRun.ffs_batch

(2.16 KiB) Downloaded 231 times

BatchRun 2022-05-17 000000.000 [Warning].log

(1.32 KiB) Downloaded 228 times

the test folder structure is:

C:\test\from
C:\test\from\a
C:\test\from\b
C:\test\to


running this will produce the duplicate sync warning.

however, i think it should not.

1. the 1st folder pair syncs everything except "b"

2. the 2nd folder pair syncs only "b"

therefore, there should be no overlap between any of the folder pairs. therefore, there should be no warning about overlap.

either i misunderstand how the sync is functioning, or there appears to be an edge case in the warning detection that does not property detect this configuration.

thanks!

[Plerry]

The warming is about an overlap between the base folders, and given your description, this warning is correct.
But apparently you have taken care of this potential risk, likely by proper definition of your Include and/or Exclude Filter.

[Zenju]

Yes the warning should not be shown in this case. TODO. viewtopic.php?t=7180

[ladarrius]

Yes the warning should not be shown in this case. TODO. viewtopic.php?t=7180

oh i guess this is known, thanks for confirming!

[Zenju]

Fixed in FFS 11.24! Finally!

The warning now will only come up if there is an actual conflict (:= file or folder accessed by multiple base folders of which at least one access is a (planned) write operation). No more false-positives.
As a bonus, the warning will now exactly say which file paths are causing the conflict:

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

C:\folder 💾 subfolder\file.txt
C:\folder\subfolder 👓 file.txt

💾 is write access, 👓 is read access

Things like

Folder pair1: C:\Source -> D:\Target   Include filter: *.txt
Folder pair2: C:\Source -> D:\Target   Include filter: *.cmd


Will NOT trigger the warning anymore, because they do not intersect, thanks to the mutually exclusive filter setting.

To make the warning work correctly in all cases, FFS doesn't even try to parse filter settings. It just checks if there are file paths that are part of multiple folders, and at least one is written to.

So common scenarios with read-only access like "one source, multiple targets" will also not trigger the warning:

Folder pair1: C:\Source -> D:\Target1
Folder pair2: C:\Source -> E:\Target2
Folder pair3: C:\Source -> F:\Target3


https://www.mediafire.com/file/hpcz776l3iscm4e/FreeFileSync_11.24_%255BBeta%255D_Windows_Setup%25284%2529.exe

[ladarrius]

oh sweet very nice thanks!!!

[aj_blackman]

Hi with the last release, I started getting this warning which wasn't there before. I have multiple base folders all syncying to the same target folder in update mode (moving development programs from there projects to a production common executable area) there are no conflicts, everythings works as it should I just started receiving this warning.
As mentioned in other topics this configuration isn't recommend, but worked fine until now.
I just ignore the warning, but thought you should be aware.

[Zenju]

Hi with the last release, I started getting this warning which wasn't there before. I have multiple base folders all syncying to the same target folder in update mode (moving development programs from there projects to a production common executable area) there are no conflicts, everythings works as it should I just started receiving this warning.
As mentioned in other topics this configuration isn't recommend, but worked fine until now.
I just ignore the warning, but thought you should be aware.

There are no bugs to my knowledge, so the warning is probably correct.

[xCSxXenon]

Hi with the last release, I started getting this warning which wasn't there before. I have multiple base folders all syncying to the same target folder in update mode (moving development programs from there projects to a production common executable area) there are no conflicts, everythings works as it should I just started receiving this warning.
As mentioned in other topics this configuration isn't recommend, but worked fine until now.
I just ignore the warning, but thought you should be aware.

There are no bugs to my knowledge, so the warning is probably correct.

I have had this recently too. I have a folder
"Z:\Software\Software for Customer Computers\Tweaking Repair"
syncing to
D:\OneDrive\PC\Tweaking Repair
and in the same config I have folder
D:\OneDrive
syncing to
[Keys]\OneDrive

This was throwing an error, and rightfully so. I didn't care that I had to run the sync twice. I did, however, decide to fix eventually. I added
Z:\Software\Software for Customer Computers\Tweaking Repair
to sync to
[Keys]\OneDrive\PC\Tweaking Repair
directly. This solved the double-running, but was throwing the error. I had forgotten to exclude
\PC\Tweaking Repair
from the initial D:\ to [KEYS] sync. Once I added that, it stopped throwing the error message.

This is just my example to maybe help figure out where the fault in your config may be

[aj_blackman]

seems the issue is config vs reality,

when I say get *.exe from all the base folders, to a single target folder
it assumes that there is a conflict as potentially there can be
in reality each folder has unquie filenames, so there is no actual conflict
my solution is to specify the filename in each folder filter that I want to sync, painfull
but doble

filesystem:
/dev/app1/exe/ has 1 file app1.exe
/dev/app2/exe/ has 1 file app2.exe

problem config base - filter - target (Throws errors)
D:/dev/app1/exe/ - *.exe - E:/bin/
D:/dev/app2/exe/ - *.exe - E:/bin/

fixed config: base - filter- target (No error)
D:/dev/app1/exe/ - app1.exe - E:/bin/
D:/dev/app2/exe/ - app2.exe - E:/bin/

[Zenju]

problem config base - filter - target (Throws errors)
D:/dev/app1/exe/ - *.exe - E:/bin/
D:/dev/app2/exe/ - *.exe - E:/bin/

Looks like a legit race condition. The intersection of files (*.exe) covered by both folder pairs is non-empty.

If you'd post the full warning message that FreeFileSync is showing, this would become more clear, as it includes example paths.

[aj_blackman]

this is the actual error
9:11:26 PM Warning Some files will be synchronised as part of multiple base folders.
To avoid conflicts, set up exclude filters so that each updated file is included by only one base folder.
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe

I touched one file, there are 21 folders pointing to a single folder

[Zenju]

FreeFileSync is showing individual conflict pairs, which is confusing. It's better to aggregate by conflict group => TODO. In your case, there's a single conflict group of 21 items, caused by a single write:

C:\local\bin 💾 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe
C:\local\bin 👓 CorReader.exe

Ideally, the conflict items should be shown in the order of the folder pairs: TODO

It seems you're using the "Update" variant. In this case the reads (👓) are really "do nothing", and perhaps (???) should be disregarded. TODO: Clarify

If disregarded, multi-pair syncs like
A -> B
B -> C
would not issue a warning anymore, if the two pairs are logically to be run one after another, but still show a warning if e.g. a file is copied (A -> B) while at the *same* time is set up to be copied from B -> C.

The former case means, that the user would have to run a sync two times to get everything in sync. Sounds awkward, but should not otherwise be a problem for sequential dependencies between folder pairs.

[Zenju]

All changes have been implemented into FreeFileSync 11.29, relase planned for later today.

[Zenju]

If disregarded, multi-pair syncs like
A -> B
B -> C
would not issue a warning anymore, if the two pairs are logically to be run one after another, but still show a warning if e.g. a file is copied (A -> B) while at the *same* time is set up to be copied from B -> C.

The former case means, that the user would have to run a sync two times to get everything in sync. Sounds awkward, but should not otherwise be a problem for sequential dependencies between folder pairs.

Turns out ignoring "equal" *is* a problem (= never in sync): viewtopic.php?t=10042

A -> C wants to create files
B -> C wants to delete the same files

[ProKesTom]

I'm switching to FreeFilesync from AllwaySync. In the AllwaySync environment, what you call a conflict was just a common situation. A user could define three or more directories that they wanted to sync, and if a similar situation occurred, the program simply compared the "conflicting" files and copied the latest version to all the directories. If a file in one of the directories was deleted between synchronizations, the latest version was copied there as well. This happened if the program was running and in automatic, batch mode. If, on the other hand, it was run manually, it just issued a warning and waited for the user's decision.
This behavior could be modified using the Error-handling setting for different situations, for each synchronization task separately.
Couldn't the "conflicts" be handled similarly here?