summaryrefslogtreecommitdiff
path: root/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn
diff options
context:
space:
mode:
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.mdwn47
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]]