Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ben 2898 client error invalid request #141

Closed

Conversation

andreilupuleasa
Copy link
Collaborator

No description provided.

BEN-2898: fix MetadataDirective
BEN-2898: increase version
@@ -75,6 +74,7 @@ def copy(self, src_name, dst_name):
try:
extra_args = {
'ContentType': source_obj.content_type
'MetadataDirective': 'REPLACE',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this change. It will certainly not resolve the BEN-2898, and will further introduce a non-required difference from django-filer master branch, if we'll ever want to update our fork to a newer version.
BEN-2898 originates froma PATCH (rename folder) request, and in that case, looking in Sentry, it really wanted to copy the same file into itself: src_path= 'prod/filer_public/pbsfortwayne/Show Logos/Series Logos/Edits_of_EVOLUTION EARTH-HorizWhiteLogo/1c62e1463d_EVOLUTION EARTH-HorizWhiteLogo_resize_Oct-03-2023:15:37.png', dst_path=
'prod/filer_public/pbsfortwayne/Show Logos/Series Logos/Edits_of_EVOLUTION EARTH-HorizWhiteLogo/1c62e1463d_EVOLUTION EARTH-HorizWhiteLogo_resize_Oct-03-2023:15:37.png'

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not able to reproduce though, if renaming a folder with the same name, there are validations in place, before doing the actual rename, and the response is "{"name":"A folder with the same name and parent already exists."}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly and from the skyzyx comment, if I'm understanding correctly you have to make s3 treat the object as a new object.

Here's the catch: you need to read the properties of the object you want to maintain, and re-apply them when you replace an object with itself (i.e., an in-place update) because otherwise S3 will either ignore them, or reset the values to default (e.g., the ContentType value).

S3 is kinda dumb that way, but if you understand that S3 treats a object-copy the same way that it treats a fresh upload, this approach makes sense. You must explicitly set the properties that you want on the new copy and/or updated object. S3 doesn't maintain any state in this case.

Make sense?

aws/aws-sdk-php#274

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants