If a conflict occurs during a synchronization (i.e. the file has been changed on both sides), there are various conflict resolution approaches, which you can configure for a connection. The solution strategies are (in short):
- Winner / Loser
With this strategy, you set which side "wins" in the event of a conflict. For example, if you set the file system as a winner and a file has been changed on both sides, the change on the SharePoint will be overwritten by that on the file system.
This is actually the most used method. - Warn and continue
In the event of a conflict, the file is skipped, which means only one warning is logged and the file is not synchronized. Of course, this leads to an inconsistent state and is therefore rarely used. You would need to monitor the warnings to manually merge files that have been skipped. - Keep Both
Here you can set a "focussed" entity (primary). If there is a conflict, a copy of the file is created on the secondary side (indicated by a postfix on the filename (L2CC-CONFLICT)) and the file is copied from the primary to the secondary entity. You then have the version of the primary on the secondary entity as the actual file, but you also have the changed version of the secondary (the conflict file) as “backup”. This variant then requires manual merging of the changes in both files on the secondary side.
This variant was implemented based on multiple customer requests, but it has emerged over time that this can only be handled in very few cases (namely those with extremely few conflicts) as it needs manual merging. - Fail and abort
With this setting, the synchronization is aborted if a conflict occurs – this is the default setting.
A detailed description of the conflict resolution strategies can also be found in the user documentation, page 29ff.
Note
We understand that “newest version wins” sounds like an interesting conflict resolution, but due to the nature of scheduled synchronization and the possibility, that users edit the same file on two different entities at the same time, we decided against a timestamp-based conflict resolution.
A short example to explain why this conflict resolution could cause major data-loss problems:
There is one Word document with 3 pages of text in SharePoint and on the File System. User A, operating on SharePoint, adds 2 more pages of content to the file and saves the changes at 13:45 PM. There is no sync yet as it is scheduled for 13:50 PM. User B opens the same file on the File System (the original 3 pages version), notices a comma missing in the first sentence, corrects it and saves the file at 13:47 PM. The sync is performed and because the latest timestamp is 13:47 this version of the file will win and the SharePoint version (containing the 2 pages of newly added content) will be overwritten and any changes made to it will be lost.