Markus, you may have found a bug in jclouds. Can you add a test to SwiftBlobIntegrationLiveTest[1] and try adding leading zeros to the part number in SequentialMultipartUploadStrategy[2]? Also can you open a JIRA issue[3] to track this? Thanks!
[1] jclouds/apis/swift/src/test/java/org/jclouds/openstack/swift/blobstore/integration/SwiftBlobIntegrationLiveTest.java [2] jclouds/apis/swift/src/main/java/org/jclouds/openstack/swift/blobstore/strategy/internal/SequentialMultipartUploadStrategy.java [3] https://issues.apache.org/jira/browse/JCLOUDS On Mon, Jun 30, 2014 at 11:14:02AM +0200, Markus von Rüden wrote: > Hey there, > > > I have an issue with the jclouds-cloudfiles-us API. > > Here is the scenario: > > * I have a file randomly created > * the file has a total file size of 809 bytes > * the file name is 'file.txt' > * I now upload that file to rackspace cloudfiles-us (Region: Chicago) > * it is a multipart upload with a chunk size of 80 bytes > > In the container at cloudfiles I get the following objects: > > * 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. > > If I download the uploaded file (manually from the ui or programatically > with jclouds) the download order is: > > * file.txt/1 > * file.txt/10 > * file.txt/11 > * file.txt/2 > * ... > * file.txt/9 > > and therefore my initial file does not match with the > uploaded/downloaded file. > > Is this a known problem? > Is this a jclouds, rackspace, openstack issue? > > Do you have any ideas how to solve this? > > If this is a bug, to whom do I need to speak to get started? > > > Kind regards > Markus > > -- Andrew Gaul http://gaul.org/
