jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-1450) Multi-part upload against the filesystem provider should return ETag similar to S3
Date Wed, 24 Oct 2018 20:31:00 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662807#comment-16662807
] 

ASF subversion and git services commented on JCLOUDS-1450:
----------------------------------------------------------

Commit 539a9854c12514959264987d8a18e1cab40f2240 in jclouds's branch refs/heads/master from
[~timuralp]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=539a985 ]

JCLOUDS-1450: Use S3-style ETags for MPUs.

S3 uses a different ETag for multipart uploads (MPUs) than regular
objects. The ETag consists of the md5 hash of the concatenated ETags of
individual parts followed by the number of parts (separated by "-").

The patch changes the LocalBlobStore's implementation of
CompleteMultipartUpload to set the S3-style ETag before calling
putBlob() and return that ETag to the caller.

To simplify testing, a new protected method with a default NOOP
implementation is added to the BaseBlobIntegrationTest. It allows
providers to further verify MPUs (i.e. ensuring the correct ETag has
been stored alongside the object).


> Multi-part upload against the filesystem provider should return ETag similar to S3
> ----------------------------------------------------------------------------------
>
>                 Key: JCLOUDS-1450
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1450
>             Project: jclouds
>          Issue Type: Improvement
>          Components: jclouds-blobstore
>    Affects Versions: 2.1.1
>            Reporter: Timur Alperovich
>            Priority: Minor
>              Labels: filesystem
>
> When performing a multi-part upload in S3, the resulting ETag is not a content hash,
but rather a hash of the content hashes of the parts, followed by "-<number of parts>".
It would be great for the jclouds filesystem provider to have the same behavior if it's trying
to be an emulation for S3 (or Swift, which has a similar behavior for its Static Large Objects).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message