You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use the 👍 reaction to show support for this feature.
Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
Subscribe to receive notifications about status changes and new comments.
Is your feature request related to a problem? Please describe.
\OC\Files\Storage\Common::copyFromStorage routes every cross-mount MOVE through PHP. When both mounts are files_external amazons3 on the same S3 endpoint, the source is read via fopen('r') and re-uploaded via \Aws\S3\MultipartUploader. The uploader's non-seekable branch materialises each part into php://temp before dispatch, so every part transits local temp storage. Temp usage scales with object size.
If the destination rejects a part, \Aws\Multipart\AbstractUploadManager::getResultHandler records the error and continues yielding parts. Temp usage grows unbounded.
Describe the solution you'd like
Add a fast path in Common::moveFromStorage (or an \OCA\Files_External\Lib\Storage\AmazonS3::copyFromStorage override). When source and destination are both AmazonS3 on the same endpoint, dispatch \Aws\S3\MultipartCopy (server-side UploadPartCopy with x-amz-copy-source).
Bytes stay on the S3 side. No PHP staging. Wall-clock reduces to seconds regardless of object size.
Precondition: the destination tenant's principal must hold s3:GetObject on the source bucket.
Describe alternatives you've considered
Lower uploadPartSize and concurrency on the mount. Shrinks per-part footprint. Keeps O(N) buffering.
Bucket-side LifecycleConfiguration AbortIncompleteMultipartUpload. Cleans up after the fact. Unsupported by NetApp StorageGrid.
Tip
Help move this idea forward
Is your feature request related to a problem? Please describe.
\OC\Files\Storage\Common::copyFromStorageroutes every cross-mount MOVE through PHP. When both mounts arefiles_externalamazons3 on the same S3 endpoint, the source is read viafopen('r')and re-uploaded via\Aws\S3\MultipartUploader. The uploader's non-seekable branch materialises each part intophp://tempbefore dispatch, so every part transits local temp storage. Temp usage scales with object size.If the destination rejects a part,
\Aws\Multipart\AbstractUploadManager::getResultHandlerrecords the error and continues yielding parts. Temp usage grows unbounded.Describe the solution you'd like
Add a fast path in
Common::moveFromStorage(or an\OCA\Files_External\Lib\Storage\AmazonS3::copyFromStorageoverride). When source and destination are bothAmazonS3on the same endpoint, dispatch\Aws\S3\MultipartCopy(server-sideUploadPartCopywithx-amz-copy-source).Bytes stay on the S3 side. No PHP staging. Wall-clock reduces to seconds regardless of object size.
Precondition: the destination tenant's principal must hold
s3:GetObjecton the source bucket.Describe alternatives you've considered
uploadPartSizeandconcurrencyon the mount. Shrinks per-part footprint. Keeps O(N) buffering.LifecycleConfiguration AbortIncompleteMultipartUpload. Cleans up after the fact. Unsupported by NetApp StorageGrid.aws s3copy. Bypasses Nextcloud.oc_filecachestays stale.ObjectStoreStorage. Cross-mountfiles_externalremains uncovered.Additional context
\Aws\S3\MultipartCopy: https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.S3.MultipartCopy.htmlUploadPartCopyIAM: https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPartCopy.htmlocc files:copyfails with large files on S3 #48194, [Bug]: Upload into group folder causes a massive delay on move operation #47856, S3 external storage: Cannot rename >5 GB files #24540.