Alex Russell 937d9af4a5 filer: delete a copied rename's old object only after the commit ...

Review follow-ups:

- The old key of a copied remote-only entry, and the old directory of a
  rename that copied one, are now deleted once the rename has committed.
  A rename that fails after the copy leaves the source entry and its
  object in place, plus an extra object at the new key.
- Every part of a multipart copy is conditioned on the ETag the copy
  started from, so an object overwritten mid-copy fails the copy
  instead of mixing versions.
- Both copy paths keep the source's server-side encryption settings.
- filer.remote.sync no longer deletes a key that a remote-only entry
  holds by the time the delete event is processed: a file deleted and
  then replaced by a remote-only rename has its content only there.

2026-10-10 20:05:34 +02:00

..

azure

fix: return NoSuchKey and drop stale entries when a remote-mounted object is gone from the remote (#11680)

2026-10-10 11:00:04 +08:00

gcs

fix: return NoSuchKey and drop stale entries when a remote-mounted object is gone from the remote (#11680)

2026-10-10 11:00:04 +08:00

s3

filer: delete a copied rename's old object only after the commit

2026-10-10 20:05:34 +02:00

remote_storage_test.go

make the remote-mount cache wait configurable per mount (#11168)

2026-09-04 23:50:11 -07:00

remote_storage.go

filer: copy a remote-only entry on the remote when renaming it

2026-10-10 19:39:17 +02:00

track_sync_offset.go

filer: keep lazy remote reads from resurrecting deleted paths (#11452)

2026-09-26 08:00:39 +08:00