[
https://issues.apache.org/jira/browse/JCLOUDS-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052251#comment-14052251
]
ASF subversion and git services commented on JCLOUDS-619:
---------------------------------------------------------
Commit 0f0207a045ef53157dac6c3d1d9daaee10671f52 in jclouds's branch
refs/heads/1.7.x from [~mvr]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=0f0207a ]
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)
