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

Francis Devereux commented on JCLOUDS-250:
------------------------------------------

Simple fix for the common case where blob names do not contain / here: 
https://github.com/brightinteractive/jclouds/tree/JCLOUDS-250

For a more general fix, perhaps a random UUID could be included in the segment 
prefix, so for a multipart blob named 'foo':
- segments would be named 'multipart/<uuid>/foo/{1,2,3,...}
- X-Object-Manifest would be 'multipart/<uuid>/foo/'

The 'multipart/' prefix is not necessary for correctness but would lead to a 
tidier namespace IMHO.
                
> 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
>            Reporter: Francis Devereux
>
> 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

Reply via email to