Just a quick question
When using the copy function to a crypted remote and using the --checksum flag, existing files are “checked” but is this same as running rclone cryptcheck against the crypted remote?
Thanks!
No. Crypted remotes don’t support hashes - if you want to check the checksums you’ll need cryptcheck
So what is technically being “checked”?
For example - lets say you run rclone copy /path/to/local remote:/path/to/crypt --retries 3 --checksum and the first pass fails (a few files failed) so on its second pass it “checks” the already copied files and tries to transfer the previously failed files. Is it just checking mod time and size?
Thanks!
The --checksum option is effectively ignored on crypted remotes.
With a normal remote (eg Amazon Cloud Drive) the cloud server generates a checksum (in Amazon’s case, Amazon will generate an MD5); rclone can read that and compare it to the local file. However with an encrypted remote the server has a checksum of the encrypted file, and so this won’t match the local file, so the option is ignored on copy/sync operations.
cryptcheck will effectively encrypt the file locally and then compare the checksum of that to the one on the remote server.
It might make sense to add a “–force-check” or similar flag on sync/copy that forces it to crypt the data and compare checksums. It becomes a trade-off; a local compute expense against a network expense. Especially on Amazon, which doesn’t have file timestamps and so a modified file may not be detected at all!
1 Like
Yes, I agree, an additional flag to force some kind of crypt check would be useful so that we wouldnt have to run a separate cryptcheck to verify the files
Thank you!
Couldn’t find that point in the documentation.
https://rclone.org/commands/rclone_copy/
-c, --checksum Skip based on checksum (if available) & size, not mod-time & size
So maybe there should be an link to the cryptcheck command?