Files
minio/cmd
Feng Ruohang 4b25f7e819 fix: return and persist checksum on federated CopyObject (#99)
The legacy etcd federation branch of CopyObjectHandler forwards the copied
bytes with minio-go Core.PutObject but never asked the remote for a checksum
and discarded any it returned, so a cross-deployment whole-object copy that
requested a checksum returned 200 with an empty checksum, and a checksum-less
source did not gain the S3 default CRC-64NVME that the local path assigns. The
request was neither honored nor rejected. This is the whole-object counterpart
of #72, which repaired the same class of defect for federated UploadPartCopy.

When a server-side checksum is wanted -- explicitly requested, inherited from a
multipart source, or the CRC-64NVME default for a checksum-less object, all
already captured in dstOpts.WantServerSideChecksumType -- the forwarded
PutObject now streams a trailing checksum of that type, so the remote computes
and persists it and echoes it in the response. The value the remote reports for
that exact write is bound into objInfo.Checksum, matching how the local
CopyObject path carries checksums into the CopyObjectResult. Reading the value
from the same UploadInfo that produced the ETag keeps the pair bound to one
write.

Only the requested algorithm is returned; a malformed or absent remote value
leaves objInfo.Checksum unset, so an ordinary copy that wanted no checksum
still returns none. Two small mapping helpers convert between the server's
hash.ChecksumType and the minio-go request type and response field.

New end-to-end tests drive the real federation branch through
getRemoteInstanceClient and minio-go into a second in-process deployment and
assert that CRC32/CRC32C/SHA256/CRC64NVME and the no-algorithm default are all
returned in the CopyObjectResult and persisted on the destination, and that a
requested algorithm never leaks other algorithms into the response.

Fixes #99

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L7qJqWwy8oFA6aCXWRzXQe
Signed-off-by: Feng Ruohang <rh@vonng.com>
2026-09-07 10:32:59 +08:00
..
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-04-09 07:28:39 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-04-09 07:28:39 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-04-09 07:28:39 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-04-09 07:28:39 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00