Hi,
Alright, I figured this one out.
First, the reason you're having an s3ql_metadata_bak_0 object right
after the upgrade is that the upgrade itself backups up the metadata
*after* having added the _pre21 suffix to the existing backups.
Secondly (and contrary to what I said before), this should nevertheless
work fine, because the object metadata (metadata about the storage
object holding the file-system metadata) is upgraded when the object is
renamed (from s3ql_metadata to s3ql_metadata_bak_0).
Thirdly, there is a bug in all versions of S3QL that prevent it to work
properly if the bucket prefix contains a plus. This is what initially
prevented me from reproducing your problem.
Fourth, there is a bug in recent S3QL versions when reading object
metadata created by S3QL 1.x. There is a function that appears to return
a string, but it actually returns a
email.headerregistry._UnstructuredHeader instance that looks and behaves
like a string.
During the upgrade of the metadata, this object (instead of a string) is
then pickled and stored - and when it is then loaded again, S3QL
correctly complains that this is an unsafe pickle that attempts to
instantiate a weird class.
The reason that this does not happen when doing the upgrade in two
separate steps is that the more recent S3QL version never looks at the
metadata object created by the 1.x version - it gets turned into a
backup during the first upgrade, and gets a _pre21 suffix in the second
upgrade.
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
