mirror of
https://github.com/versity/versitygw.git
synced 2025-12-23 05:05:16 +00:00
a606e57bbd
Fixes #1565 Fixes #1561 Fixes #1300 This PR focuses on three main changes: 1. **Prioritizing object-level lock configuration over bucket-level default retention** When an object is uploaded with a specific retention configuration, it takes precedence over the bucket’s default retention set via `PutObjectLockConfiguration`. If the object’s retention expires, the object must become available for write operations, even if the bucket-level default retention is still active. 2. **Preventing object lock configuration from being disabled once enabled** To align with AWS S3 behavior, once object lock is enabled for a bucket, it can no longer be disabled. Previously, sending an empty `Enabled` field in the payload would disable object lock. Now, this behavior is removed—an empty `Enabled` field will result in a `MalformedXML` error. This creates a challenge for integration tests that need to clean up locked objects in order to delete the bucket. To handle this, a method has been implemented that: * Removes any legal hold if present. * Applies a temporary retention with a "retain until" date set 3 seconds ahead. * Waits for 3 seconds before deleting the object and bucket. 3. **Allowing object lock to be enabled on existing buckets via `PutObjectLockConfiguration`** Object lock can now be enabled on an existing bucket if it wasn’t enabled at creation time. * If versioning is enabled at the gateway level, the behavior matches AWS S3: object lock can only be enabled when bucket versioning status is `Enabled`. * If versioning is not enabled at the gateway level, object lock can always be enabled on existing buckets via `PutObjectLockConfiguration`. * In Azure (which does not support bucket versioning), enabling object lock is always allowed. This change also fixes the error message returned in this scenario for better clarity.