On 11/30/2014 12:50 AM, Shannon Dealy wrote:
>
>> I suspect this is because you copied the objects into a new bucket, but
>> did not include the associated metadata.
>>
>> Which tool did you use to do the copy, and how did you call it?
>
> I used the AWS command line tools:
>
> aws s3 sync s3://src-bucket s3://dest-bucket
>
> It did fail part way through the transfer, so I restarted it with the
> same command.
>
>> When you use the S3 Management Console
>> (https://console.aws.amazon.com/s3/home) to look at the "s3ql_metadata"
>> object in the original bucket and the copy, does it have the same
>> metadata?
>
> While the s3ql_metadata file is there, in the new bucket it is missing
> all of the keys except the Content-Type. Not sure whether this means
> the fsck without cached data trashed it, or if amazon's sync was
> trashing the transfered data because I used it incorrectly or it is
> broken somehow.
I think you have to blame the aws tool for this one. If you think
fsck.s3ql is at fault, that's easy enough to check: just run the sync
command again and see if the metadata is present before running fsck.s3ql.
I don't know if that's a bug in aws, or if you're using it incorrectly,
but "gsutil" is able to copy buckets including metadata (in case you
want to try that).
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
