Below is an example of -vv from an rclone move -vv --delete-empty-src-dirs command I did. It was using serverside move. I was moving undecrypted data between two crypted remotes. (on google drive).
2018/02/11 15:50:27 DEBUG : directory name: Rmdir: contains file: filename
2018/02/11 15:50:27 DEBUG : directory name: Failed to Rmdir: directory not empty
2018/02/11 15:50:27 DEBUG : other directory name: Removing directory
2018/02/11 15:50:32 DEBUG : other directory name: Removing directory
2018/02/11 15:50:32 DEBUG : other directory name: Rmdir: contains trashed file: other filename
For a full explanation of the lunacy that made this happen:
This other thread is very boring and poorly written. I made this new thread to ask a much simpler and more specific question.
I’m worried that this scenario can make rclone move unreliable, but it almost seems from the feedback like rclone move is able to avoid rmdir on directories that have files magically added back into them at the last moment, hopefully. I am planning to dig through meatspace storage to find this drive. This is a backup of a drive I haven’t used since 2011 but last I checked still worked, so I may be able to repair any damage dealt to this backup, although, if by some miracle no damage has been done, great.
I found this thread after googling for that “Rmdir: contains trashed file” message: it is showing on my logs when I rclone sync a rather large local file system to my main Encrypted Google Drive remote.
What exactly does that message mean? That rclone sync tried removing the remote directory as it was empty on the local file system, but could not because, albeit empty of ‘regular’ files, it contained a reference to a file in Google Drive’s trash?
If yes, I understand that the remote no longer matches the local file system, as the former will contain (empty) durectories which are not present on the latter. Is that correct? And, how can it be “fixed”? Just empty the Google Drive trash (via Google Drive’s Web interface?) and then sync again?