blob: 57a17445563a931b9d4e58e28b681e9d1becb758 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
### Please describe the problem.
Originally spotted/reported: https://github.com/datalad/datalad/issues/1020
If that is mandatory, then I guess there should be some error message.
### What steps will reproduce the problem?
create a remote repo without specifying version, i.e. of version 5 and copy data into it
### What version of git-annex are you using? On what operating system?
6.20160923+gitgd1dabb3-1~ndall+1
### Please provide any additional information below.
Output from running http://www.onerussian.com/tmp/v6-push.sh with argument which specifies annex version within remote
[[!format sh """
$> ./v6-push.sh 5 2>&1 | grep '>>>'
>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
$> ./v6-push.sh 6 2>&1 | grep '>>>'
>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
>>> 123
"""]]
[[!meta author=yoh]]
> The data loss bugs are fixed in [[!commit ee309d694161d0f416420db6c4efb834c813351e]].
>
> I am not sure yet why the keys database lacked an entry for the file;
> perhaps something to do with it being a v6 unlocked file in a v5
> repository.
>
> Ok.. Seems that cloning to a v5 repository, and then copying/getting
> objects into it, and then upgrading to v6 reproduces the problem with the
> keys database. The inode cache does not get populated for unlocked files
> on upgrade. Also, unlocked files stay as pointer files even when their
> content is present in annex/objects. Fixed the upgrade process to handle
> this case.
>
> [[fixed|done]]] --[[Joey]]
|
