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
files_copy_batch_v2 api seems extremely slow
Hi,
I've written a python script which handles merging updates from a patch directory into the main data directory.
Simply it takes a list of files from the patch directory, copies them into the build dir and tags the patch directory as closed.
If I do this manually and let the Dropbox client handle it, it takes about 5-10 seconds regardless of how many files are involved. However using the API, each file takes approximately 5 seconds. This is confounding, is there any reason? If the Dropbox client (on Windows) uses a different API for the same purpose, what is it?
#adding to batch:
batch.append(dropbox.files.RelocationPath(from_path=remote_patch_dir + k + kj,
to_path=remote_build_dir + kj))
#issuing copy call:
res = dbx.files_copy_batch_v2(batch)
jobid = res.get_async_job_id()
while True:
if dbx.files_copy_batch_check_v2(jobid).is_complete():
break
sleep(10)jdboomzap Yes, unfortunately due to some changes on the backend, performance on this endpoint worsened recently. I'll bring this up with the team to see if we can improve this in the future, but I can't make any promises.
The desktop client does use a different mechanism for some functionality, but there isn't a way to replicate that on the API I'm afraid.
- Greg-DB
Dropbox Staff
jdboomzap Yes, unfortunately due to some changes on the backend, performance on this endpoint worsened recently. I'll bring this up with the team to see if we can improve this in the future, but I can't make any promises.
The desktop client does use a different mechanism for some functionality, but there isn't a way to replicate that on the API I'm afraid.
Hi there, found this really old thread and the issue still exists when copying files from one path to another via the /files/copy_batch_v2 endpoint. Were there ever any improvements made to fix the slowness? because for me, the process keeps going on forever, and I am hardly able to copy files from one to another path.
FYI, I am using c# with Dropbox NuGet package v6.26.0 installed. Most of the time, when I hit Files.CopyBatchV2Async with a list of RelocationPath, half of them failed and then I have to try again to copy them. Kind of using the same approach mentioned in this thread by using a while loop to track the progress of the copy process in Dropbox, and once it's completed, I then check for failed files and do the same operation again for failed files.
Any help would be appreciated. Thanks.- Greg-DB
alirameez I don't have any specific updates to share, but the team does continually make improvements if/when possible. If I try running the code that was included in the original post (though I lowered the 'sleep' value since it runs faster than that for me) now, it does run faster than described there originally.
The original post only mentioned slowness though, and didn't indicate that the operations were actually failing. If you're seeing failures returned, make sure to check each RelocationBatchErrorEntry to see the reason for the failure.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
