mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-10-14 01:58:33 +02:00
Alex Russell
d5cff0a38f
Renaming a file under a remote.mount whose content exists only on the remote (never cached, or remote.uncache'd) lost it: the new entry kept the old RemoteEntry, deleting the old entry deleted the old object, and with no chunks nothing ever wrote the new key. filer.remote.sync could not finish the rename either, since the old object was already gone. moveSelfEntry now copies such an entry's object to the new key before it touches anything, and the new entry gets the RemoteEntry of the copy. The copy is a new optional RemoteStorageObjectCopier interface, implemented for S3 with CopyObject up to 5 GB and UploadPartCopy above that; the multipart copy carries the source's metadata and, where the remote supports tagging, its tags. When an existing target is overwritten, its delete keeps the remote object (the copy replaced it) and its event is marked metadata-only so the sync leaves it alone too. A remote-only rename that leaves its mount, or whose remote cannot copy, is refused instead of deleting the only copy. Empty entries and entries with local data rename as before. UpdateFileMetadata builds its copy source with the same helper, which escapes each key segment and keeps the slashes.