Calculating the size of all deleted files

[rk90]

I had posted a similar question in the past and was told that I need to call `/2/files/list_revisions` to calculate the size of the deleted files. I collect the list of deleted items by listing each folder, but the Dropbox response does not tell whether the deleted item is a file or a folder. Since there is no way to tell which item is a file and which one is a folder, I have to call `list_revisions` in try/except to avoid failures due to calling `list_revisions` on folder. If I knew which items in the list are folders, I would have filtered them out and this would have saved several thousand API requests.

[Greg-DB]

Thanks for the feedback! I'm sharing it with the team.

[rk90]

Greg,

I have a pretty large data set with several hundred thousand deleted items. Moreover, the way Dropbox data are structured really sucks (i.e. If I list namespace and then list each folder using the namespace id, the paths returned are relative to the namespace. This is not an issue for team member or team folders, but for shared_folders this is a huge issue since all paths in response will  be relative to the namespace and when I try to call `list_revsisons` on such a path, I get '409 confilict' with text 'path not found'.).

One would ask why I am listing each folder via namespace and the answer is I am operating on a business account with thousands of users. If I were to list each member's folder individually I would end up listing the same shared/team folders multiple times (with recursive set to True, there is no way to ignore the already listed folders even if you wanted to). In order to list the shared folders just once, I list team members' folder with 'include_mounted=False', then I walk through the namespace and list each shared_folder. This works but if I try to call `list_revisions` on any deleted item that was returned, it simply fails because the path is relative to the namespace. Now in order to get the absolute path of the folder, I have to make another request.

I have made so many feature requests, but none have been implemented. Dropbox is a big name only because they established themselves when there was no real competition otherwise with this kind of service you wouldn't survive even one day. 

Are there any workarounds/suggestions or I am on my own here?

[Greg-DB]

Thanks for the detailed feedback!

For listing revisions of files, /2/files/list_revisions does support namespace-relative paths directly. (I.e., supply the "path" parameter as "ns:12345678/relative/path/to/file".) Perhaps that would work better for your use case?

[rk90]

I've already tried namespace relative path (ns:<namespace_id>/relative/path/to/file) but still got 409.

How long do you think it will take for you guys to implement a better reporting API where we can simply run the report to calculate the size of deleted items rather than calling `list_revisions` on each item. When do you think the fix to return the type of the deleted item will be implemented? Are works on these feature requests progress?

[Greg-DB]

Can you share the code and parameters you're using, and the output you're getting in that case? That way I can take a look and see what the issue may be. (Make sure you check the response body for the error. I suspect it's 'not_found' in this case, but it always good to check to be sure.)

I've sent your feature requests along to the team, but I can't promise if or when they would be implemented.