Feature Request - Allow deactivation or control parameters related to the "significant differences" protection

[theglem]

It would be very nice if it could be possible to de-activate the check that aborts the synchronization when there are too many differences between the two directories to be synchronized. Alternately, there could be a configuration parameter that specifies the maximum percentage of files that can be modified during a synchronization.

Now, why is that feature useful?

I run the FreeFileSync program in 2-way mode from an automated batch process to synchronize report templates created and modified on two independent servers. It is a valid use case to delete or modify a large number of template files exceeding more than 50% of the files (between two calls to FreeFileSync). There can be a large amount of simultaneous changes to the files on each server because these changes are part of a publish process on each server that can involve a lot of files.

At the moment, when 10 or more modifications are performed and more than 50% of the files are changed, the synchronization aborts. When this condition happens, a manual intervention is required and there is no nice possible recovery. If I delete the sync.ffs_db files on both sites and restart a synchronization, a lot (I mean a lot) of deleted files may reappear.

Also, since the directories to sync are specified as part of an automated task, an error in specifying the directories is not an issue or source of error in this particular case.

Beside this undesirable protection in my case, I find the FreeFileSync program extremely useful.

[Zenju]

Just check option "don't show this warning again" or disable "WarnSignificantDifference" in GlobalSettings.xml

[theglem]

Thanks for the hint.

I changed the WarnSignificantDifference in GlobalSettings.xml and then the synchronization is performed even if the warning is still logged and the program returns a warning status code of 1 (%errorlevel% in Windows). I can certainly use this although an option to completely disable the protection (no warning logging, no warning return code) would have been a better behavior in my case. Also, it would have been nice to have that setting documented in the expert section of the HELP file.

Thanks again for your help, this was helpful and very much appreciated.