On Jan 03 2016, Alexandre Gonçalves <[email protected]> wrote:
> Yes. I forgot that. In fact I didn't know that was necessary.
Reading the changelog is always a good idea :-).
>
> I managed to put the old system up again. The installed s3ql version is
> 2.12.
>
> In order to check if the fs mounts and since I had changed the oauth2
> token, I had to update the old auth file:
>
> Old:
> [gs]
> storage-url: gs://ideiao-bkp
> backend-login: oauth2
> backend-password: 1/Lely6ZhHlSUna_BWBCXEJremOJz0tXfjsnSb7gMrygo
> fs-passphrase: ***********
>
>
> New:
> [gs]
> storage-url: gs://ideiao-bkp
> backend-login: oauth2
> backend-password:
> 1/mo6BOlKCGIJhkIJCg3ZGjlLE6XyxesggPybESUTDuPtIgOrJDtdun6zK6XiATCKT
> fs-passphrase: ***********
>
>
> *The size of the token is completely different... Is this normal?*
Not sure.. I'm not an oauth expert.
> In the old system, when mounting with the new authfile, I get:
>
> mount.s3ql --authfile /root/scripts/.s3ql_authinfo2 --cachedir /root/.s3ql/
> gs://ideiao-bkp /media/1/
> Using 10 upload threads.
> Autodetected 4034 file descriptors available for cache entries
> Requesting new access token
> Using cached metadata.
> Uncaught top-level exception:
> Traceback (most recent call last):
> File "/usr/local/bin/mount.s3ql", line 9, in <module>
> load_entry_point('s3ql==2.12', 'console_scripts', 'mount.s3ql')()
> File
> "/usr/local/lib/python3.4/site-packages/s3ql-2.12-py3.4-linux-x86_64.egg/s3ql/mount.py",
>
> line 130, in main
> (param, db) = get_metadata(backend, cachepath)
> File
> "/usr/local/lib/python3.4/site-packages/s3ql-2.12-py3.4-linux-x86_64.egg/s3ql/mount.py",
>
> line 391, in get_metadata
> db = Connection(cachepath + '.db')
> File
> "/usr/local/lib/python3.4/site-packages/s3ql-2.12-py3.4-linux-x86_64.egg/s3ql/database.py",
>
> line 71, in __init__
> cur.execute(s)
> File "src/cursor.c", line 990, in APSWCursor_execute.sqlite3_prepare
> File "src/statementcache.c", line 386, in sqlite3_prepare
> apsw.CorruptError: CorruptError: database disk image is malformed
>
Are you sure you fixed the old system completely? This looks exactly as
if your harddisk corrupted some data.
> and verifying gives this:
>
> s3ql_verify --debug --authfile /root/scripts/.s3ql_authinfo2 gs://ideiao-bkp
> 2016-01-04 00:06:53.978 10013 MainThread
[..]
s3ql_verify won't help, it checks the data that's stored in the
backend. In your case, the local (cached) copy of the metadata is
corrupted.
> What can I do?
Try to get an uncorrupted version of your .s3ql directory from
somewhere.
If that's not possible, move the local copy out of the way and run
fsck.s3ql. It will re-download whatever you most-recently uploaded to
the backend.
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.«
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
