Optionally use internal-remote transfer instead of local-to-remote if possible

I often change the path of folders of dozen GB in my source disk, and when I backup/synchronize it with the remote backup on the cloud, RClone move those several GB of data from the local source to the destination cloud, spending a lot of time in doing a useless task, since those GBs are already on the cloud in another position.

It would be great if RClone could be aware that those files are already on the cloud and copy them from cloud to cloud, which is a much faster task and does not use bandwidth.

Does anybody know if this is possible, and if not, should I post a feature request?

It is possible today.

Add --track-renames to your sync command.

  --track-renames                        When synchronizing, track file renames and do a server-side move if possible
  --track-renames-strategy string        Strategies to use when synchronizing using track-renames hash|modtime|leaf (default "hash")

I would only use default hash strategy to be on the safe side - but it only works on remotes supporting hashes.

So I move your post to Help and Support:slight_smile:

I think what we need is somebody to update documentation as today when I look at rclone sync I won't see that this flag exist.

It is buried in global flags page where there 700 flags listed with very brief descriptions. Not useful at all.

1 Like

Do you mean that "rename" in this context includes files moved to another directory?

yes it sort of applies to full path:


moved to


should be tracked.

Testing is the best option always:)

Please note that default tracking works by hash so it wont work for crypt remotes (hash not supported). In that case you have to use:

--track-renames --track-renames-strategy modtime

One warning too, and I argue this is actually a bug, is that rclone will track when it can't be uniquely identified. So if you move multiple files with the exact size and mod time (or within mod time tolerance), it will pick the first one.

(it is actually not the most impossible scenario either)

this is why I said hash is the safest. Crypt remote does not support hashes at the moment. You have to decide yourself.

Here some discussion about this exact issue:

And possible solution but it complicates all setup a bit:

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