One month down in 2025: How are your resolutions coming along? Check out how to get back on track here.
Forum Discussion
Jonathan M.17
8 years agoNew member | Level 2
Files ListFolder and ListFolderContinue slow
I have been using the API Files.ListFolder and ListFolderContinue to fetch meta data of all my files and folders. Functionally it is working but each request takes 3-8 seconds to come back with the page of 2000 results. I can't believe this is normal. Anyone else getting this? Out of interest I tried it with Python and .NET SDKs, same results.
Also the metadata PathDisplay doesn't always return the display path. I think it is the FolderMetadata that gets it wrong, the parent folders are not done in Display format, instead they are Lower. Possibly only for shared folders but I haven't debugged it further.
- Greg-DB
Dropbox Staff
The performance you see from ListFolder[Continue] will be account-specific, and dependent on a variety of factors, such as how much file activity there is in the account. The more files and file activity in the account, the more likely it is for these calls to take longer. We're always looking into ways to improve performance, but there isn't a way to improve this from the client-side.
Also, unfortunately, that path_display behavior is sometimes expected. Even in path_display, the original casing isn't always available for all components. There's a note about this in the API v2 documentation, under "Case insensitivity":
Also, while Dropbox is case-insensitive, it makes efforts to be case-preserving. Metadata.name will contain the correct case. Metadata.path_display usually will contain the correct case, but sometimes only in the last path component. If your app needs the correct case for all components, it can get it from the Metadata.name or last path component of each relevant Metadata.path_display entry.
We understand this is non-ideal of course, and I'll forward this on to the team as feedback, but I can't make any promises as to if or when this might be improved in the future.
- Jonathan M.17New member | Level 2
Thanks Greg for the helpful reply :)
As it is only the initial fetch that takes time I can probably live with it for now. I next need ot understand how to monitor for changes after I have a model of the content. I couldn't find a clear pattern in the API docs, is there one? My assumption is that I can hold the cursor from my last call to ListFolderContinue and periodically check this. How long are the cursors valid for?
- Greg-DB
Dropbox Staff
That's correct, you should store the last cursor you received and occasionally call back to ListFolderContinue using it to retrieve entries for just the things that have changed since the last time you called.
Cursors don't expire, but they can become invalid in some (relatively rare) scenarios, so make sure you handle ListFolderContinueError.Reset:
https://dropbox.github.io/dropbox-sdk-dotnet/html/T_Dropbox_Api_Files_ListFolderContinueError_Reset.htm
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.5,942 PostsLatest Activity: 4 hours ago
If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!