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
We need to remove this limitation and add some tests to cover objects with trailing slash.
JT Olio
Feb 15
oh this is a surprise if you're coming from s3 - you can have objects that have a slash at the end. we can't really know from an s3 perspective if a path is a prefix or object just from its name only
Michał Niewrzał
11:17 AM
Good point. I just copied this part and didn't think much about it. I think when keys are encrypted then key with slash will work well but it might be problematic with unencrypted keys. I don't have strong opinion here, I can remove that limitation on the top of this change or I can just leave it as is until someone will complain.
JT Olio
3:35 PM
slashes are actually not encrypted, even with otherwise encrypted paths, as slashes are the key derivation boundary. i think it's worth removing the limitation and actually adding some tests for the object-with-trailing-slash case
The text was updated successfully, but these errors were encountered:
During conversation on https://review.dev.storj.io/c/storj/uplink/+/12265 turns out that we should not limit copy object source and target key to be woiuthout slashes (we are talking about this code)
We need to remove this limitation and add some tests to cover objects with trailing slash.
The text was updated successfully, but these errors were encountered: