You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The download behavior (and upload behavior) contains several bugs and deviations from sfcli.exe. Sync-SfItem does NOT work like sfcli.exe, the documentation claiming so is wrong. I observed the following bugs/deviations and submitted a pull request from my personal branch where the probles are fixed. The following bugs were fixed in my branch, but apply only to downloads. The same faulty logic problems exist in the upload routines and have not been touched.
If 'Move' or 'Synchronize' is used, 'recursive' is no longer forced. This was a deviation from sfcli.exe
When 'CreateRoot' is used and the source is a ShareFile folder, Sync-SfItem would create the parent of the source folder in the destination. This was a deviation from sfcli.exe. Example: If the source on ShareFile was /Folder1/Folder2/Folder3 and -CreateRoot is used, then Sync-SfItem would create Folder2/Folder3 in the destination.
When 'CreateRoot' is not used, Sync-SfItem will still create the parent folder of the items being synchronized in the destination. This was a deviation from sfcli.exe. Example: if the source on ShareFile was /Folder1/Folder2/Folder3 and -CreateRoot is NOT used, then Sync-SfItem would create Folder3 in the destination.
When 'CreateRoot' is used, Sync-SfItem will now behave in one of two ways. If the source is only files, then the parent of those files will be created in the destination. If the source is a folder, the folder will be created in the destination. Otherwise, if 'CreateRoot' is not used, the parent folder is not created at all in the destination. Example: If the source is /Folder1/Folder2/Folder3 and -CreateRoot is used, then Sync-SfItem will create Folder3 in the destination, otherwise no folder is created in the destination and only files (and subfolders, if recursive is used) are copied.
When 'Move' is used, folders would be deleted even when 'KeepFolders' was used if the folder did not have any child items. This was a bug, and a deviation from sfcli.exe. In this scenario, if someone used the -move switch and the source was /Folder1/Folder2/Folder3 and additionally there was a Folder4 subfolder, then Folder4 would be deleted if it was empty, even if -KeepFolders was used.
The text was updated successfully, but these errors were encountered:
The download behavior (and upload behavior) contains several bugs and deviations from sfcli.exe. Sync-SfItem does NOT work like sfcli.exe, the documentation claiming so is wrong. I observed the following bugs/deviations and submitted a pull request from my personal branch where the probles are fixed. The following bugs were fixed in my branch, but apply only to downloads. The same faulty logic problems exist in the upload routines and have not been touched.
The text was updated successfully, but these errors were encountered: