comment

1 files changed, 22 insertions, 0 deletions

diff --git a/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment
new file mode 100644
index 000000000..4f90ddfa6
--- /dev/null
+++ b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:36:34Z"
+ content="""
+Thing is, git-annex get does not update the file in place. Only once the
+entire file is downloaded, and its content is verified correct is it moved
+into a place where you can access it.
+
+So, it seems much more likely to me that the content of the file, as
+originally added to git-annex, was bad, and the it had just finished
+verifying the content and moving it into place when you interruped the
+command.
+
+Please check with `git annex fsck` on the file and see if it determines
+it has the content git-annex expects it to have.
+
+However, I notice you're using a v6 repository. Is the file an unlocked
+file? It's possible that in that specific case there could be a bug.
+I've interrupted `git annex get` on a nearly daily basis for years, but
+v6 is still experimental and not as well tested.
+"""]]