Error Example:
Error while writing data to entity '<entityName>': Folder '<folderPath>' was marked to be deleted but it contains <#> files not marked to be deleted. This is probably due to misconfiguration. There might be folders included in the results of one side of the sync, but not on the other. Write operation is aborted.
Causes and Resolutions:
This error happens, when the Cloud Connector tries to delete a Folder, as it was marked to be deleted, but the content of the folder itself wasn’t marked to be deleted which causes a conflict. As this issues cannot be resolved automatically, you need to check what caused the issue and then manually resolve it.
The error can be caused by different circumstances which are listed below ordered by probability:
- Changing Case on Folder Name (most common reason)
The main cause for this is a change in casing (upper to lower, or vice versa). The change in case makes the key value different, even though SharePoint and the file system don't care about the case. "FOLDER" and "folder" are the same name, but not to the key evaluation system. Please check the affected folder on both sides to see if a change like this could be causing the issue.
To resolve this, you need to rename the folders on both sides, so they have the exact same name with the exact same case.
- Moving Folders that Had New Content Added in Other Entity
The second known cause is triggered by moving a folder on one side but also then adding content to the folder (which is still in its original position) on the other.
To resolve this, you need to manually adjust all the content so that the folders on both sides are in the same place and with the same content.
It may require temporarily moving the content (so it appears deleted on both sides), syncing, and then adding the content back so that it's mirrored again. This should be rare though as it requires you to both create a conflict by changing the folders AND moving one of them.
- Multiple connections to same endpoints
If different connections point to the same folders / SharePoint libraries this issue can be caused by connections changing files without the other connection being aware. Different connections cannot point to same locations with bi-directional syncs.
- Checked Out Content
Checked out content can cause this issue as well. You need to check in all files and folders in the library and the next sync should run without errors.
- Using ID as Primary Key Instead of FilePath
Next known cause is due to setting the primary key as the ID and not leaving it as the default blank (which is the FilePath). If the folder is deleted and readded, it gets a new ID (as SharePoint doesn't recycle those), which then causes this error because the underlying items may still have their original IDs.
This error can be resolved by removing the ID from the primary key field and synchronizing again with the default setting.
- Custom Views that Exclude Content
Another known cause is due to using a view in SharePoint that excludes folders. This method will exclude the folder but NOT the sub-content in the folder, making it appear the folder is gone but the content is not. The behavior is a known issue with SharePoint views, as they don't act in SP as they do in Cloud Connector for excluding content.
- Using Protected Folder Names
Protected folder names in SharePoint, such as "_files" which are usually hidden, can also cause this issue. The Connector reads and creates the folders as they are needed for the path to the files, but as the folder doesn't "exist" the second time around, it marks it to delete.
|
