[
https://issues.apache.org/jira/browse/JCLOUDS-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052248#comment-14052248
]
ASF subversion and git services commented on JCLOUDS-619:
---------------------------------------------------------
Commit a39eadce50e3bc37abc0e47564ef1698529bec81 in jclouds's branch
refs/heads/master from [~mvr]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=a39eadc ]
JCLOUDS-619: Introduce MultipartNamingStrategy to generate part names correctly.
> Cloudfiles/Swift order problem when using multipart and having more than 9
> parts
> --------------------------------------------------------------------------------
>
> Key: JCLOUDS-619
> URL: https://issues.apache.org/jira/browse/JCLOUDS-619
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Affects Versions: 1.7.3
> Reporter: Markus von Rüden
>
> There is an issue when uploading to a swift blob storage using multipart and
> having more than 9 parts.
> Here is an example scenario:
> * a file is randomly created (total file size of e.g. 809 bytes)
> * the file name is 'file.txt'
> * that file is uploaded rackspace cloudfiles-us (Region: Chicago)
> * it is a multipart upload with a chunk size of 80 bytes
> In the container at cloudfiles/swift the following objects get created:
> * file.txt (the manifest, size: 0 byte)
> * file.txt/1 (80 bytes)
> * file.txt/10 (80 bytes)
> * file.txt/11 (9 bytes)
> * file.txt/2 (80 bytes)
> * file.txt/3 (80 bytes)
> * ...
> * file.txt/9 (80 bytes)
> As you already can see, the object names are ordered by name and
> therefore by chars and do not consider the part numbers as numeric values.
> The issue was initially posted to the mailing list [1].
> [1] http://www.mail-archive.com/[email protected]/msg04958.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
