update
This commit is contained in:
parent
d2ed1b3a99
commit
9d86d02b3d
1 changed files with 8 additions and 12 deletions
|
@ -46,17 +46,13 @@ Running the copy job again, I am still getting the same error as above (as expec
|
|||
>>>
|
||||
>>> That's a v1 key, but a corrupt form of the key; it's missing the
|
||||
>>> size and mtime fields that all WORM keys have in v1. And
|
||||
>>> the filename is itself a key, a v2 SHA512 key. My guess at what
|
||||
>>> happened is that these were created when you did the `git annex copy`
|
||||
>>> to the v1 bare repo.
|
||||
>>> the filename is itself a key, a v2 SHA512 key. These were
|
||||
>>> created when you did the `git annex copy to the v1 bare repo.
|
||||
>>> In v2, git-annex-shell takes a full key object, while in v1,
|
||||
>>> it takes a key name and a backend name. This incompatability
|
||||
>>> leads to the weird behavior seen.
|
||||
>>>
|
||||
>>> So, assuming none of these are the only copy of your data
|
||||
>>> (which you should check), the best thing to do is delete those
|
||||
>>> keys, and re-run the copy now that it's upgraded. Not sure
|
||||
>>> it even makes sense to fix the crash. I should probably focus
|
||||
>>> on fixing what let these mixed keys be created by the mixed-version
|
||||
>>> copy.
|
||||
>>>
|
||||
>>> On second thought, you shouldn't delete anything. I'll simply
|
||||
>>> make the v2 upgrade detect and work around this bug.
|
||||
>>> I had suggested you delete data.. don't. On second thought,
|
||||
>>> you shouldn't delete anything. I'll simply make the v2 upgrade
|
||||
>>> detect and work around this bug.
|
||||
>>> --[[Joey]]
|
||||
|
|
Loading…
Reference in a new issue