Open ferristocrat opened 2 years ago
Completed:
In Progress:
Estimation ticket: https://github.com/storj/storj/issues/4875
This issue appears when a >5gb file is moved on the source which in the following reports was on TrueNAS systems while they are using the TrueNAS Storj integration via the sync option. Multipart uploads are enabled and Serverside copy is triggered.
Convo https://storj.slack.com/archives/C03CD69JF6J/p1682359306889639
Old Report (April 23') "3>ERROR : Backups/Backup/Adobe File Backups/Shawn Adobe Data1.zip: Failed to set modification time: NotImplemented: A header you provided implies functionality that is not implemented status code: 501, request id: 17577FA900427860, host id:"
New Report https://supportdcs.zendesk.com/agent/tickets/29781
Background
What is the problem/pain point?
Many S3 libraries such as boto3 for Python set a object size threshold, after which, uploads and copies will default to multipart upload. Given that we do not currently support multipart copy (link to that endpoint) this default threshold will return an error.
What is the impact?
Customers expect their integrations to “just work” when Storj advertises S3 Compatibility. This feature gap frustrates customers as they’re onboarding and if not resolved, we will lose business.
Why now?
Customers are asking for this and it helps round out our compatibility with the “core” features of the S3 API.
Requirements
Assumptions
Out of Scope
User Story
S3 Method: UploadPartCopy - Uploads a part by copying data from an existing object as data source.
Acceptance Criteria
Request Params
Response Elements
Measures of Success
Useful Links