Note to self: S3QL versions prior to 2.10 (and all of the 1.x versions) did not read the object metadata on object copy and object rename. Therefore, the unsafe pickle could have been there for quite some time. However, this still does not explain why the object "survived" the upgrade without being renamed.
The only other explanation would be that this object has actually been created after the upgrade (e.g. by calling mount.s3ql). But then I don't understand how it could have been renamed from s3ql_metadata to s3ql_metadata_bak* without triggering the same error. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
