You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Deleted files are automatically restored.
As shown in sample 1, "delete_V2" alone will succeed in deletion, but as in sample 2, the combination of "unshare Folder" and "delete_V2" will automatically restore the deleted file (folder).
...
Thank you very much. I can now reliably handle it in the following way:
1) Unshare the folder and wait until it is complete.
2) Wait for the folder to be re-added.
3) Delete the folder.Note that I get a "too_many_write_operations" error when I try to delete the re-added folder immediately. So I need to wait a bit for the delete and retry the delete if I get this error.
However, this way is the safest way I have ever done, as it can reliably determine the end of processing when the folder is successfully deleted.
Thank you for your reply.
I understand why the deleted files are restored.
So I tried the following.
1) Unshare the folder using "unshare Folder:".
2) Wait for the above completion until "result.isComplete" becomes true using "checkJobStatus:".
3) After finishing the above, delete the above folder using "delete_v2:".
The result works well when there are few subfolders and files, but unfortunately the copy is restored when there are many subfolders and files.
So, before doing the above "unshare Folder:", I did the following:
0-a) Use "deleteBatch:" to delete the subfolders and files under the above folder.
0-b) Use "deleteBatchCheck:" and wait until deleteBatch finishes.
This process allowed me to delete even large shared folders.
Is this process flow correct? Or is there a better way?
Greg-DB
Dropbox Staff
Dropbox StaffYes, unfortunately the re-addition of the retained copy can take some time to complete even after the unshare job itself is "complete". To accommodate that, you can delete the contents first if you wish, but it may be more direct to wait until re-addition is complete after the unshare and then delete it. You could do so by adding a sufficient delay, or checking for the existence of the re-added folder before issuing the delete.
Thank you for your reply.
Is there a way to distinguish between the original folder and the re-added folder?- Greg-DB
Yes, you could distinguish between shared and not shared folders by checking the metadata, e.g., by using getMetadata. If it's a shared folder, the DBFILESFolderSharingInfo.sharedFolderId in the returned DBFILESFolderMetadata.sharingInfo will be set. It will not be set if it is not a shared folder.
Thank you very much. I can now reliably handle it in the following way:
1) Unshare the folder and wait until it is complete.
2) Wait for the folder to be re-added.
3) Delete the folder.Note that I get a "too_many_write_operations" error when I try to delete the re-added folder immediately. So I need to wait a bit for the delete and retry the delete if I get this error.
However, this way is the safest way I have ever done, as it can reliably determine the end of processing when the folder is successfully deleted.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
