This morning I have made a mess: I succeeded in loosing tons of videos in a few seconds.
That’s not rclone fault, but I think it would be better to think if it’s possible to add a kind of protection for dumb users like I have been.
I have mounted a Google Drive proctected folder on a local mount: rclone mount 0limit-secret:Plex/ /media/0limit
Then I moved around a little in my folders; then I decided to continue moving data from my local drive to Google Drive, issuing:
rclone -v --stats 10 move ./ 0lmit-secret:Plex/
The mistake I did was that “./” was indeed /media/0limit instead of /media/localdrive.
Rclone didn’t noticed that “./” was really 0limit-secret:Plex/ and started “moving” from one remote Google Drive folder to the same one.
And after a few second the disaster had been done:
utente@PCINVA025575:/media/0limit$ rclone --stats 10s -v --transfers 1 move ./ 0limit-secret:Film/ --bwlimit 4000
Enter configuration password:
password:
2017/09/02 13:28:35 INFO : Starting bandwidth limiter at 3.906MBytes/s
2017/09/02 13:28:39 INFO : Encrypted drive '0limit-secret:Film/': Modify window is 1ms
2017/09/02 13:28:41 INFO : ######### (2014) [720p][x264][AC3][2ch].mkv: Deleted
2017/09/02 13:28:42 INFO : ####################### (2015).srt: Deleted
2017/09/02 13:28:44 INFO : ################### (2015) [480p][x264][AC3][6ch].mkv: Deleted
2017/09/02 13:28:46 INFO : ############### (1995) [480p][x264][AC3][6ch].mkv: Deleted
2017/09/02 13:28:47 INFO : ###### (2016) H264.mkv: Deleted
2017/09/02 13:28:48 INFO : ######### (1995) [1080p][x264][AC3][6ch].mkv: Deleted
and so on.
What did happened?
Rclone tried to copy the source file to the destination, that was THE SAME FILE; date & size were (obviously) the same, therefore it didn’t need to copy the file again, so it MOVED the file… By DELETING the source… That was even the destination.
BOOM! Terabyte-level data loss achieved.
Dic@head I am
However I think it would be nice for rclone to check on his own mounted shares to check is another dumb users like me is making the same mistake and avoid it
It is a dangerous tool. Sorry to hear this. There had been issues about this with requests for options like “max-delete” and other flags but in this case you would never have applied that switch. Hmm.
I wonder if drive-use-trash should really be the default and if it should have been a flag for drive-skip_trash instead
Certainly, but setting environmental variables at log-in effectively sets the default options any way you like without forcing changes on users that may break their scripts and such. Options that do not break functionality (e.g., --dry-run) should generally default to false/off otherwise for a more predictable ux, particularly across versions.
Thanks everyone who reminded the --drive-use-trash option.
However I think my report should have pointed out that while rclone “understands” that source and destination folders are the same if you use the remote:/dir/path format (it quits with the message Nothing to do as source and destination are the same), it’s not able to understand it if source or destionation are rclone mounts.
I think that it shouldn’t be too much difficult to do that; after all, if you have locally mounted a remote f/s there are rclone demons taking care of interfacing the local dir to the remote f/s.
I have been a dumb and obviously I do not blame rclone, I just think that such a check would be nice and maybe not too much difficult to implement.
But the current directory was in fact 0lmit-secret:Plex.
Normally rclone just compares the source and destination strings to see if they are the same, however if they are local paths it would be quite easy to normalise them first.
Can you please make a new issue on github and I’ll see about putting that in.
