mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
e2bfeef066
* Fix S3 MoveFile/CopyFile failing on files larger than 5GiB S3FileBackend.MoveFile, CopyFile and DecodeFilePathIfNeeded used the minio-go CopyObject call, which performs a single server-side PUT-copy. S3 rejects copy sources larger than 5GiB, so any move/copy of a file over 5GiB fails with: The specified copy source is larger than the maximum allowable size for a copy source: 5368709120 This breaks, among other things, finalizing an `mmctl import upload` of an import archive larger than 5GiB on S3-backed installations (the upload streams fine, then the .tmp -> final rename fails). Extract the shared copy logic into a copyObject helper that picks the right S3 operation by source size: CopyObject for sources up to 5GiB, and ComposeObject (server-side multipart copy via UploadPartCopy) for larger sources, supporting objects up to 5TiB. Small files keep using a single CopyObject; only files over 5GiB pay for multipart. The size is checked explicitly rather than relying on ComposeObject's own single-copy fast path, which is only taken when the source range Start is -1, a value its input validation rejects (Start must be non-negative), so it is unreachable here. * Add unit tests for S3 copyObject copy-vs-compose routing Extract the copy-routing logic into copyObjectWithClient, which takes a small s3CopyClient interface (StatObject/CopyObject/ComposeObject) so it can be tested with a mock. The exported behavior of copyObject (and its callers MoveFile/CopyFile) is unchanged; *minio.Client satisfies the interface. Tests cover the three branches: - source > 5GiB -> ComposeObject (multipart copy), not CopyObject - source <= 5GiB -> CopyObject, not ComposeObject (incl. the boundary) - StatObject error -> propagated, neither copy is attempted * make mocks --------- Co-authored-by: wiggin77 <[email protected]> Co-authored-by: Hanzo Dev <[email protected]>