renaming folder on path1 and path2 results in 2 path-tagged copies of all contents in both paths

[rinkjames]

Hi, started using rclonesync as a lightweight and open source alt to Google Backup and Sync and it's been great. I recently ran into this issue though (see title). Not sure it's a bug per se, probably more an enhacnement, but the ability to detect renames and sync those instead of syncing the files themselves would be very welcome from my perspective.

In my case, I renamed a folder on my local machine (path1) and renamed the corresponding folder on my Google Drive (path2), and rclonesync seems to have detected this as a change for all the files in both of those directories, so they were all copied both ways with path1 or path2 appended. This makes sense if a file was actually edited in both paths since the last sync, but for renaming a containing folder it's a bit overkill in my opinion. Also have to clean out both directories now and do --first-sync I expect. Is there a way to disable this feature for renaming folders to avoid this in the future?

[cjnaz]

Yeah, that's the behavior I would expect. Not handled very well.

Limitations (to be added to the README):

8. Renaming a folder on side A results is deleting all files on side B and then copying all files again from A to B. rclonesync sees this as all files in the old directory name as deleted and all files in the new directory name as new. Similarly, renaming a directory on both sides to the same name will result in creating _Path1 and _Path2 files on both sides. Quite a mess. The most effective and efficient method of renaming a directory is to 1) rename it on both sides, then 2) do a --first-sync.

Note that the rclone team is working to incorporate rclonesync functionality directly into rclone with a new rclone bisync command, so rlonesync's days are numbered. I'm very pleased to have written and supported this tool, and also look forward to the integrated solution. I'll leave this issue open, tagged as a limitation. @ivandeex

[rinkjames]

Thanks for the info and README edit @cjnaz. Exciting to hear that rclone will implement this code as bisync. I wonder whether in time @ivandeex will work on limitations like this one...