Child Item

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).

// sample 1
[[userClient.filesRoutes delete_V2:path]
    setResponseBlock:^(DBFILESDeleteResult * _Nullable result,
    DBFILESDeleteError * _Nullable routeError, DBRequestError * _Nullable networkError) {
    if(result) {
    } else {
    }
}];

// sample 2
[[userClient.sharingRoutes unshareFolder:shareID]
    setResponseBlock:^(DBASYNCLaunchEmptyResult * _Nullable result,
    DBSHARINGUnshareFolderError * _Nullable routeError, DBRequestError * _Nullable networkError) {
    if(result) {
        [[userClient.filesRoutes delete_V2:path]
 	    setResponseBlock:^(DBFILESDeleteResult * _Nullable dresult,
    	    DBFILESDeleteError * _Nullable routeError, DBRequestError * _Nullable networkError) {
    	    if(dresult) {
            } else {
            }
        }];
    } else {
    }
}];

Even if you delete from unshare or unshare from delete, it will be automatically restored.

However, I can delete it if there is some time between unshare and delete. But the result is very volatile.

Is there a way to safely delete by running unshare and delete at the same time?

Find more posts tagged with

API

Abuse

Accepted answers

Nue

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.

All comments

Greg-DB

Deleting a shared folder will "unmount" that shared folder, but will not "unshare" it.

Unsharing a shared folder will "unmount" and "unshare" it for all users and the owner can choose whether or not the other members should be able to keep a copy, via -unshareFolder:leaveACopy:. The owner will always retain their own copy though. The act of retaining the owner's own copy is effectively a matter of re-adding a non-shared copy of the folder though, which is why you may see this conflict with a delete call.

For that reason, you should not perform both the delete and the unshare at the same time. If you want to unshare a shared folder, and delete the retained copy, you should wait until the unshare is complete before issuing the delete.

Note that the unshareFolder operation can run asynchrounously though, so the actual unshare job may not be complete by the time the unshareFolder call itself returns. You need to check if unshareFolder returned an async job ID to you, and then poll checkJobStatus to check if the job is complete. Only once it's complete should you then proceed to delete the retained copy, if you wish to.

Nue

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

Yes, 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.

Nue

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.

Nue

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.