[Vonng]

Present since the bulk delete was introduced upstream; reproduced on RELEASE.2026-11-09T00-00-00Z and RELEASE.2026-10-26T00-00-00Z. Deployments with more than one pool are not affected.

erasureServerPools.DeleteObjects checks every name with checkDelObjArgs, but on a single pool it still sent all entries to the drives, and it cleared the error of an entry that a drive reported as found. The names of an S3 DeleteObjects request come from the XML body, which the path checks of the request URL do not see, and a local drive joins the name to the bucket directory. A name with a .. segment therefore reached another bucket or the meta bucket:

• with a version ID, a caller allowed to delete in one bucket removed a version in another bucket, including one under COMPLIANCE retention, because the Object Lock check looks at the request bucket;
• from a versioned bucket, without a version ID and with s3:DeleteObject alone, the request wrote a delete marker on an object of another bucket or on stored system metadata such as a bucket's .metadata.bin;
• the bulk lock was taken on the normalized name, that is on the object of the other bucket, and two aliases of one object in a request waited on each other until the lock timeout.

In a distributed single pool the remote drives refuse such a path (guardedStorage), the local drives of the node that took the request did not.

Change

Right after the check, entries that failed it keep their error and the rest of the request runs as a request of its own, before any lock, lookup or drive call. A request whose names are all valid does not enter the new code. The check is the one a single-object DELETE applies.

Behavior: on a single pool an entry whose name fails the check now returns XMinioInvalidObjectName for that entry instead of being reported as deleted, as it already did with more than one pool. The other entries of the request are deleted as before.

Tests

• TestPoolsBulkDeleteInvalidNames: object layer, on the one bulk lock of a single node, on a pool that locks per set, and on two pools. Fails on the first two without the fix.
• TestBulkDeleteObjectLockNameOutsideBucket: S3 request of a user who may delete in one bucket only; a version under COMPLIANCE retention, the object and the stored bucket metadata of another bucket stay. Fails without the fix.

Both names match existing race steps in go.yml, and the second one the Object Lock gate in release.yml.

🤖 Generated with Claude Code