* filer.remote.gateway: keep the remote object while a version under a delete marker is locked
Every version of a versioned bucket uploads to the object's key, so on a
remote without versioning that object is the only remote copy of the
latest version. A delete marker deleted it even when a version still held
a legal hold or unexpired retention. Keep it while any version of the key
is locked, the same rule the filer uses before pruning a remote entry.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* filer.remote.gateway, filer.remote.sync: say that earlier versions need remote versioning
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* filer.remote.gateway: delete a kept delete marker's object once the version lock is released
A delete marker kept for a locked version stays unstamped. When an
update or delete leaves a version that carried a legal hold or retention
without an active lock, look up the key's latest version and, if it is
still that unstamped marker, run the delete again. Only changes to
versions that carried a lock trigger it, so the noncurrent mark and tag
updates of unlocked versions do not send repeat remote deletes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* filer.remote.gateway: test the kept delete marker retry through the bucket mount
The retry reads the key's versions through a filer client parameter, as
the rename helpers do, so a test can check the mapped object key and the
marker stamp, and that lock-releasing updates and deletes reach it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* filer.remote.gateway: check the lock release lookup goes to the gateway's filer
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
