Thank you for the suggestions -- I followed up on both and have additional data. I also want to acknowledge upfront: you are right that this is not a bug. rclone is working as designed. I am reframing this as a feature request for improved progress reporting during S3 server-side multipart copy.
On --dump=headers
I ran the transfer with --dump=headers and it was very informative. The headers confirm rclone is firing UploadPartCopy requests immediately at t=0 with no delay on its side. Every request has Content-Length: 0 -- rclone sends only the X-Amz-Copy-Source and X-Amz-Copy-Source-Range headers and AWS handles the copy internally. I understand now why rclone cannot report bytes transferred -- it genuinely sees zero bytes.
However, --dump=headers also confirms that rclone does receive a 200 OK response for each completed part, containing X-Amz-Copy-Source-Version-Id. So rclone knows exactly when each part completes. It receives this information in real time but does not log it or update the progress display.
On aws s3 copy tool comparison
You asked how aws s3 cp handles statistics for multipart server-side copy. I tested it on a 394 GiB object:
Completed 3.6 GiB/394.1 GiB (257.2 MiB/s) with 1 file(s) remaining
aws s3 cp shows bytes transferred, total size, and transfer rate -- updating continuously throughout the copy. It uses the same UploadPartCopy API. The difference is that aws s3 cp updates its progress display each time a part completes. rclone receives the same part completion responses but does not use them.
The feature request
rclone already logs "Starting multipart copy with 85 parts" -- so it knows the total part count upfront. It receives a 200 OK for each completed part. It has everything needed to show meaningful progress. The two specific asks are:
-
Log each part completion at DEBUG level in the standard -vv log, e.g.:
source.vbk: server-side copy part 4/85 complete
-
Update the live progress display to show part completion counts rather than 0 B / 0 B, 0%, e.g.:
Transferred: 0 B / 394.111 GiB, 0%, 0 B/s, ETA -
Server-side copy: 4 / 85 parts, 5%
Elapsed time: 1m16s
The 0 B transferred and 0% are technically correct -- rclone transferred zero bytes itself. But displaying them for 40 minutes with no other indication of activity is deeply misleading. Part count is the natural unit of progress for server-side copy and rclone has it in real time.
Additional finding: incomplete multipart cleanup
When I killed the rclone transfer with Ctrl-C, the --dump=headers log showed rclone sent AbortMultipartUpload and received 204 No Content. However, rclone backend list-multipart-uploads still showed the upload present with 4 completed parts. rclone cleanup also failed silently (exit 0, no effect). The parts were only removed after running aws s3api abort-multipart-upload directly.
By contrast, killing aws s3 cp with Ctrl-C left zero incomplete multipart uploads immediately.
This may be a separate issue worth looking at -- rclone's AbortMultipartUpload on SIGINT receives a 204 but does not actually clean up the parts, and rclone cleanup does not compensate for this.