Files
minio/cmd
Ayush Sharma e7e87402ed fix: forward the legal hold as an Object Lock header on federated CopyObject
A cross-deployment CopyObject that requests
`x-amz-object-lock-legal-hold: ON` answered 200 while the destination
carried no hold. The resolved value reached the remote as ordinary user
metadata, `X-Amz-Meta-X-Amz-Object-Lock-Legal-Hold`, so nothing applied it.
Retention requested on the same copy survived, which is what made the loss
easy to miss.

The federation branch passes the resolved metadata map straight to
`Core.PutObject` as `PutObjectOptions.UserMetadata`. minio-go's `Header()`
writes the typed lock fields first, then prefixes every UserMetadata key it
does not recognise with `x-amz-meta-`; `supportedHeaders` covers
`x-amz-object-lock-mode` and `x-amz-object-lock-retain-until-date` but not
`x-amz-object-lock-legal-hold`, and `isAmzHeader` does not match it either.
Retention therefore arrives as real headers and the hold does not. The
high-level `validate()` that would have rejected the key never runs, because
`Core.PutObject` goes straight to the low-level PUT.

Carry the hold on the typed `LegalHold` option and forward a cloned map with
the raw key removed. The clone matters twice: typed fields are written before
the UserMetadata loop, so a leftover raw key would add a bogus `x-amz-meta-`
entry beside the correct header, and the proxy's own response and event
metadata are rebuilt from the resolved values rather than the forwarding map,
which no longer carries the hold.

Retention stays in the map deliberately. It already passes through as a
standard header, and moving it to the typed `RetainUntilDate` field would
format with `time.RFC3339` and truncate a retain-until date to whole seconds.

The new test asserts the wire: the remote must receive
`X-Amz-Object-Lock-Legal-Hold` and never the `x-amz-meta-` spelling, and the
destination version must actually store the hold. It fails without the change
with "legal hold forwarded as user metadata [ON]".

Fixes #166

Signed-off-by: Ayush Sharma <72848455+Aeirx@users.noreply.github.com>
2026-09-10 13:15:10 +05:30
..
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-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-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