Dropbox remote-to-remote move: Error message, but actually worked

I also tried that: In my original post, I was using --low-level-retries 30. Exact same issue, just three times more failed retries.

You have to do that math and however long it takes, you have to make a lot of retries.

It's rather strange Dropbox errors out that much on a server side move.

I don't think so. This will just keep failing forever. And that's because the initial move request actually gets carried out by Dropbox (despite returning the timeout error), so all subsequent requests for the same operation must fail. Rclone's re-tries are mere re-requests for the same move operation, rather than re-checks of whether the initial request has succeeded. Since the API call used in this operation (/move_v2) is synchronous and returns either a success or an error, but never a job id, there is no direct way to check the job for success later.

I'm not an expert on using HTTP APIs, and I have no clue why Dropbox replies with "gateway timeout". I agree that this is very strange behavior. The primary bug here is most probably with Dropbox and not with rclone -- but I have a feeling that Dropbox won't change much anytime soon...

To circumvent the issue, it seems to me that using asynchronous API calls (like /move_batch) might be more reliable than the synchronous endpoint (/move_v2) that rclone uses. My move operation takes a long time, and it seems that other elements of the HTTP transmission chain are too impatient for that and give up too early.

One question: Can a client-side firewall cause this issue? I'm issuing these commands from behind a rather aggressive corporate firewall, which might interfere with the connection. On the other hand, the 504 response does seem to come from the Dropbox edge server, which hints at an issue in the chain of nodes that is involved in executing this request on Dropbox's side. I've been using Dropbox's own clients for years from behind the same firewall and without issues, despite very large transfer operations.

I think it's more an issue on dropbox and the response it's getting back and timing it out.

@ncw - any thoughts?

I do agree that you can (maybe) tweak some settings to work around but the problem will still remain as the issue needs to get fixed on the other side. I don't think you are seeing any issues on your items along the way like firewalls and such as you getting a response back from Dropbox with the 529.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.