An rclone sync with --track-renames runs like a normal sync, but keeps track of objects which exist in the destination but not in the source (which would normally be deleted), and which objects exist in the source but not the destination (which would normally be transferred). These objects are then candidates for renaming.
After the sync, rclone matches up the source only and destination only objects using the --track-renames-strategy and either renames the destination object or transfers the source and deletes the destination object.
The actual implementation works like this - you can compare this with the source code:
When --track-renames is enabled the sync is done as normal, but
- if an object is only in the source, it is added to the
renameChecklist and not transferred - if an object is only in the destination it is added to the
dstFilesmap keyed by path and not deleted
At the end of the sync rclone then
- creates the
renameMapfrom thedstFilesusing --track-renames-strategy to define the map key - matches all of the files in
renameCheckagainstrenameMapand if they match, renames them, and if they don't transfers them - After this, any remaining files in
dstFilesare deleted.
So you can see why this case is not being renamed - it is because there is a matching src and dst and a normal sync is done.
We could potentially modify the first part of the algorithm to this
- If src and dst match then skip, otherwise
- Add src objects to the
renameChecklist - Add dst objects to the
dstFilesmap keyed by path
- Add src objects to the
This would then store all of the transfers to be done at the end which would bulk up the renameCheck list to include all the transfers. The algorithm would proceed as above.
I think this would work. It has the disadvantage of not doing any syncing until it has looked at all the files and it stores the whole transfer in memory before starting which will definitely use more ram.
Thoughts?