Files ListFolder and ListFolderContinue slow

[Jonathan M.17]

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]

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.17]

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]

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