Confirming my understanding: does --checksum on a crypt remote silently become size-only?

Help and Support
1

Hi all,

I recently found silent drift in a ~2-year-old crypt backup and traced it to --checksum. I've already fixed it, but before I trust the fix I'd like to confirm my understanding is correct on every point.

My setup

  • Windows → Koofr via a crypt remote (koofrCrypt:), daily rclone sync, for ~2 years.
  • A VPS mirrors the raw encrypted blobs from Koofr to HiDrive/Strato 1:1 (no crypt remote on the VPS — it just copies opaque encrypted files). So Koofr and HiDrive are byte-identical.
  • I verify integrity with rclone cryptcheck (Windows plaintext ↔ hidriveCrypt:), same crypt passwords as koofr...

What happened

cryptcheck reported differences between Windows and HiDrive, even though HiDrive is an exact copy of Koofr. I downloaded the same file from both Koofr and HiDrive: byte-identical to each other, but different from the Windows original. So the encrypted store simply never received the newest version of some files — HiDrive just inherits that backlog.

My understanding — please confirm or correct

  1. A crypt remote exposes no plaintext hash (crypt.Hash() returns none), because the only hash the underlying backend stores is of the ciphertext, which never matches the local plaintext. Correct?
  2. Therefore rclone sync --checksum against a crypt destination has no common hash and falls back to size-only — and since --checksum also ignores modtime, a file edited in place without a size change is treated as identical and never re-uploaded. Correct?
  3. This is exactly what the once-per-run NOTICE (found on line 2 of every sync log) means:
    NOTICE: Encrypted drive 'koofrCrypt:D': --checksum is in use but the source and
    destination have no hashes in common; falling back to --size-only
  4. Dropping --checksum and using the default modtime + size comparison is strictly more reliable here, because Koofr and HiDrive both support modtime (R/W). A same-size edit is then caught via the modtime. Confirmed with a manual copyto without --checksum:
    package.json: size = 968 OK
    package.json: Modification times differ by -25h3m25s:
    2026-06-08 13:02:03 (local) vs 2026-06-07 11:58:37 (remote)
    package.json: Copied (replaced existing)
  5. 968 bytes on both sides → size-only would have skipped it; modtime caught it and it uploaded.
  6. rclone cryptcheck is the only way to verify content integrity across the crypt boundary. It works by reading the nonce from each file on the crypt remote, re-encrypting the local file with that nonce, and comparing the ciphertext checksum against the underlying remote's hash — needed because crypt uses a random per-file nonce (same plaintext → different ciphertext on every upload). Correct?
  7. There is no sync-time equivalent of that nonce-based check. The "proper" fix would be storing the plaintext hash in an encrypted crypt v1 header (issue #3667 on Github), still open with no ETA. crypt: adding metadata (including hashes) to crypt files · Issue #3667 · rclone/rclone · GitHub Correct?

Run the command 'rclone version' and share the full output of the command.

rclone v1.74.3

  • os/type: windows

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[hidrive2026]
type = hidrive
token = XXX

[hidriveCrypt]
type = crypt
remote = hidrive2026:users/xyz/RCE
filename_encryption = standard
directory_name_encryption = true
password = XXX
password2 = XXX

[koofr]
type = koofr
provider = koofr
user = XXX
password = XXX

[koofrCrypt]
type = crypt
remote = koofr:RCE
filename_encryption = standard
directory_name_encryption = true
password = XXX
password2 = XXX

Thank you so much!