Dropbox v2 api error too_many_write_operations #1539
Comments
:-)
That is correct, yes.
I saw a similar thing in my testing. I think this is normal for multi-threaded uploads to dropbox. You can set
I don't think the v1 API has the same concept. |
|
Confirmed. Setting I think my main concern was that these errors were causing performance issues however it looks like that's being discussed in #1483. Will follow that issue. |
|
I use rclone on Arch linux to sync a directory to Dropbox periodically. Today I started seeing heaps of these Searching the web brings me to this bug. I added the |
|
@ncw It looks like it's actually non-trivial. When I tested, I got the errors. So I ran again just to verify, and the same files had to upload still. The uploads were not truly in sync until after several more runs I finally got through without any errors. Only seems to be happening to files change, not new ones, if that helps at all. |
|
@tskeeley this isn't under my control, alas, it is dropbox doing rate limiting. It might be that I could change the default pacer for dropbox to make it more reliable. Can you experiment with different values for |
|
@ncw You got it. I will work on doing a bunch of updates and then some
testings. I have the beta you just released for the other issue (so glad
that is fixed! :) ) so I should be good for testing. I'll work on it over
the weekend and see if I can get you a more focused answer.
…-- Thomas
Any road followed precisely to its end leads precisely nowhere. Climb the
mountain just a little bit to test it's a mountain. From the top of the
mountain, you cannot see the mountain.
-- Frank Herbert
On Fri, Aug 11, 2017 at 4:06 AM, Nick Craig-Wood ***@***.***> wrote:
@tskeeley <https://github.com/tskeeley> this isn't under my control,
alas, it is dropbox doing rate limiting. It might be that I could change
the default pacer for dropbox to make it more reliable. Can you experiment
with different values for --tpslimit to see if that makes a difference?
For dropbox the limit is 100 normally, so try numbers smaller than that.
You'll need a recent beta <https://beta.rclone.org> for that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1539 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABEkRNJw4DkWsLmu9YLKavRBcKBAvNbmks5sXBmPgaJpZM4OaFpJ>
.
|
|
FWIW, I had to set |
For others who found this issue, this improvement looks very relevant: #5156 (comment) |
Just upgraded to the latest beta to try out the new Dropbox v2 API. Thanks for all of your hard work! Much appreciated. I'm noticing a lot of files being updated while syncing which haven't changed. I assume that's due to client_modified attribute now being applied correctly.
While reviewing my log output it appears there is a high number of too_many_write_operations errors. They seem to self correct during a low level retry. It's happening frequently around every 5th or 6th file. Maybe this is normal behavior? I haven't noticed it before the update. Sorta reminds me of the "lock held by connection" errors I would see in Dropbox v1 API. Not really affecting anything but there in the background.
rclone v1.36-254-g6f71260aβ
Ubuntu 16.04 64bit
Dropbox
rclone sync Backup/foldername Anchor-Dropbox:Backup/foldername -vv --exclude .DS_Store --stats=5m
The text was updated successfully, but these errors were encountered: