when doing a "rclone check" between two remotes that are encrypted, even though rclone is not decrypting the files, the hash check should accurately compare the files, not? I mean, if there are two files that are encrypted with the same encryption to different remotes, their hash should still match, no? The reason i ask is, when doing a -vv log, only one remote lists the algorith used for the checksum. is that normal?
i guess my actual question is, when doing a check between two encrypted remotes, do i need to decrypt the data using cryptcheck, or will i be fine using the regular check, which i assume will require fewer resources?
What is your rclone version (output from rclone version)
1.55.1
Which OS you are using and how many bits (eg Windows 7, 64 bit)
Windows Hyper-V Server 2019
Which cloud storage system are you using? (eg Google Drive)
Microsoft OneDrive for Business
The command you were trying to run (eg rclone copy /tmp remote:tmp)
if i upload the same file to 2 different crypt remotes, and they have the same encryption options, the file name on both remotes is identical. therefore, the encrypted file contents should be identical too, no?
this is literally telling me i can use rclone check between two different encrypted remotes, as long as they have the same password, and that i don't need to use cryptcheck. so therefore, the hashes on the files in the different remotes should be identical:
For example, let's say you have your original remote at remote: with the encrypted version at eremote: with path remote:crypt. You would then set up the new remote remote2: and then the encrypted version eremote2: with path remote2:crypt using the same passwords as eremote:.
rclone cryptcheck checks a remote against a crypted remote. This is the equivalent of running rclone check, but able to check the checksums of the crypted remote.
[OneDriveWy]
type = onedrive
drive_id =
drive_type = business
[OneDriveWyEncrypted]
type = crypt
remote = OneDriveWy:TBA Server
filename_encryption = standard
directory_name_encryption = false
[OneDriveGina]
type = onedrive
token =
drive_type = business
are the remotes similar that you're using? perhaps that's why it's not checking the hashes. as you can see on my log in the initial post it does compute a QuickXorHash, and matches it to the other same file, for which it just says "OK"; i'm using OneDriveBusiness to OneDriveBusiness.
but i also note that it never explicitly says "Using QuickXorHash for hash comparison" like it does on the cryptcheck. i guess now i'm just curious why it's mentioning the QuickXorHash in the debug log.
and it also begs the question, if i'm backing up an encrypted remote, and i'm not encrypting/decrypting the data, what guarantee of safe transfer do i have, if it doesn't do a hash checksum as it transferring the files?
If you are making a backup of a crypt by copying the underlying encrypted data, then rclone check will work just fine and it will check the checksums. This appears to be what you are doing.
If you copy the same file to two crypt remotes then the hashes will be different as the file is different each time it is encrypted, even if the keys, etc are the same.
Let's say you have two underlying remotes called A and B and the crypt versions cryptA and cryptB.
If your backup does rclone sync A: B: then rclone check A: B: will be an excellent check, checking the checksums.
If your backup does rclone sync cryptA: cryptB then rclone check cryptA: cryptB: will not check checksums. You could use rclone cryptcheck in this case, but note that it will involve downloading the data from one side and since in your case A and B are remote then is undesirable.
Looking through the thread I think you are doing rclone sync A: B: and your rclone check A: B: seems to be checking hashes just fine.
if i may humbly make a suggestion, when doing an "rclone check", having the little "Using QuickXorHash for Hash Comparisons" notice like we get when doing an "rclone cryptcheck" would be nice, because at the moment, the only way to get the hash comparison info is to extract the debug log.
