diff options
Diffstat (limited to 'doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn')
-rw-r--r-- | doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn b/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn new file mode 100644 index 000000000..57a174455 --- /dev/null +++ b/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn @@ -0,0 +1,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]] |