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

[nopria]

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?

[kapitainsky]

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

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.

[nopria]

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

[kapitainsky]

yes it sort of applies to full path:

dir1/dir2/file

moved to

dir3/dir4/file

should be tracked.

Testing is the best option always:)

[kapitainsky]

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

[jwink3101 (Justin Winokur)]

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)

[kapitainsky]

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:

Can not use --track-renames when syncing to and from Crypt remotes?

I have an issue where if I try to sync with --track-renames between two crypt remotes then I get an error that "--track-renames ignored because the two remotes do not have a common hash". The sync works, but not with the feature I want, which I think is pretty important for use. Also I can run with --track-renames if I try between two non-crypt remotes Is this some sort of intended limitation or is there a way to work around it?

[kapitainsky]

And possible solution but it complicates all setup a bit:

Hasher