cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: Calculating the size of all deleted files

Calculating the size of all deleted files

rk90
Helpful | Level 5

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.

 

5 Replies 5

Greg-DB
Dropbox Staff

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

rk90
Helpful | Level 5

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
Dropbox Staff

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
Helpful | Level 5

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
Dropbox Staff

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. 

Need more support?