[
https://issues.apache.org/jira/browse/JCLOUDS-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751294#comment-13751294
]
Francis Devereux commented on JCLOUDS-250:
------------------------------------------
Some more thoughts on possible designs for a more general fix:
1. If jclouds created a Static Large Object (see
http://docs.rackspace.com/files/api/v1/cf-devguide/content/Static_Large_Object-d1e2226.html)
instead of a Dynamic Large Object then there would be no risk of unrelated
blobs being accidentally included because the list of segments is explicitly
specified in the manifest of an SLO (as opposed to a name prefix being
specified in a DLO).
2. It would be nice if jclouds allowed a different container from the to be
used for segments. That would avoid this issue - but only if people used it, so
IMHO adding such support couldn't be considered a complete fix.
I think that including a random UUID in the segment prefix would be the easiest
complete fix for this issue, but supporting static large objects would be a
nice additional feature. Adding support for SLO would bring some more questions
though, for example:
- would support for DLOs be retained (in which case a complete fix for this
issue with DLOs would be nice)
- if support for creating DLOs was dropped would we still leave in support for
automatically deleting segments of DLOs?
> Swift: Uploading a blob whose name starts with the name of a multipart blob
> changes the multipart blob's contents
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JCLOUDS-250
> URL: https://issues.apache.org/jira/browse/JCLOUDS-250
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Reporter: Francis Devereux
> Assignee: Francis Devereux
> Fix For: 1.7.0
>
>
> If you upload a multipart blob named "foo" and then upload a non-multipart
> blob named "foo.bar" to the same container then when you get the contents of
> "foo" they will include the contents of "foo.bar".
> This happens because CommonSwiftAsyncClient uses the blob's name as the value
> for the X-Object-Manifest header, and swift includes all blobs whose names
> start with this value when responding to a GET on the multipart blob.
> http://docs.openstack.org/trunk/openstack-object-storage/admin/content/direct-api-management-of-large-objects.html
> and
> http://www.rackspace.com/blog/rackspace-cloud-files-now-supporting-extremely-large-file-sizes/
> append a / to the end of the X-Object-Manifest header which avoids this
> issue in the common case (it can still happen if a blob with / in the name is
> uploaded, but this is likely to be uncommon because / does not commonly
> appear in filenames as it is the UNIX path separator character).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
