copyto silently fails over previously rcat-ed object
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 59.8k
- Forks
- 5.4k
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 48
Description
Before you start
- I have searched the forum and the existing issues for this problem.
- I have tested with the latest beta or stable release and can still reproduce the problem.
- This is a reproducible bug, not a usage question (questions belong on the forum).
Associated forum post URL
No response
What is the problem you are having with rclone?
If a file was uploaded using rcat, this skips populating the md5 field. If a subsequent copyto is executed over that with --checksum, the checksum check is skipped as seen in the rclone -vv output below. This probably also affects copy, I have not tested.
...
2026/06/22 12:19:28 DEBUG : 6 go routines active
2026/06/22 12:19:28 DEBUG : rclone: Version "v1.74.3" starting with parameters ["./rclone" "--config=/dev/null" "--s3-provider=Cloudflare" "--s3-endpoint=https://<REDACTED>.r2.cloudflarestorage.com" "--s3-no-check-bucket" "--s3-env-auth=true" "--s3-chunk-size=5Gi" "--s3-copy-cutoff=5Gi" "--s3-upload-cutoff=5Gi" "--checksum" "-vv" "copyto" "/srv/up/b/tempfilez/tmp.F9JSfKLfJI" ":s3:<REDACTED>...flattened.ndjson.zst"]
2026/06/22 12:19:28 DEBUG : Creating backend with remote "/srv/up/b/tempfilez/tmp.F9JSfKLfJI"
2026/06/22 12:19:28 DEBUG : Using config file from ""
2026/06/22 12:19:28 DEBUG : fs cache: renaming child cache item "/srv/up/b/tempfilez/tmp.F9JSfKLfJI" to be canonical for parent "/srv/up/b/tempfilez"
2026/06/22 12:19:28 DEBUG : Creating backend with remote ":s3:<REDACTED>...2026/06/21/"
2026/06/22 12:19:28 DEBUG : :s3: detected overridden config - adding "{qzX-7}" suffix to name
2026/06/22 12:19:28 DEBUG : fs cache: renaming cache item ":s3:<REDACTED>...2026/06/21/" to be canonical ":s3{qzX-7}:<REDACTED>...2026/06/21"
2026/06/22 12:19:28 DEBUG : <REDACTED>...flattened.ndjson.zst: size = 541214 OK
2026/06/22 12:19:28 DEBUG : <REDACTED>...flattened.ndjson.zst: Dst hash empty - aborting Src hash check <--- THIS IS A
2026/06/22 12:19:28 DEBUG : tmp.F9JSfKLfJI: Size of src and dst objects identical <--- SERIOUS PROBLEM
2026/06/22 12:19:28 DEBUG : tmp.F9JSfKLfJI: Unchanged skipping
2026/06/22 12:19:28 INFO :
Transferred: 0 B / 0 B, -, 0 B/s, ETA -
Elapsed time: 0.0s
rclone version
rclone v1.74.3
- os/version: debian 12.6 (64 bit)
- os/kernel: 6.9.7 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.26.2
- go/linking: dynamic
- go/tags: none
Built straight from https://github.com/rclone/rclone/releases/tag/v1.74.3
Operating system
Linux
Which cloud storage system are you using?
Cloudflare R2
Output of rclone config redacted
There is no config, everything runs with `... --config=/dev/null`
The command you were trying to run
See the log above
A log from the command with the -vv flag
See above
Anything else?
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the reported rcat followed by copyto command against Cloudflare R2 with --checksum, then trace the checksum and same-size decision shown in the verbose log. The fix is complete when copyto does not silently skip replacing an object solely because the destination checksum is empty, with regression coverage for this sequence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100