Open rinkjames opened 3 years ago
Yeah, that's the behavior I would expect. Not handled very well.
Limitations (to be added to the README):
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
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...
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?