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
Calculating the size of all deleted files
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
Dropbox Staff
Thanks for the feedback! I'm sharing it with the team.
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?
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
