response

1 files changed, 35 insertions, 0 deletions

diff --git a/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment
new file mode 100644
index 000000000..362609f52
--- /dev/null
+++ b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T16:48:33Z"
+ content="""
+Thank you for trying v6 unlocked mode; do note that it's still somewhat
+experimental.
+
+`git annex info` doesn't report correctly on unlocked files, which is why
+it has 0 in two places in the output you showed. I have just committed a
+fix for that problem.
+
+I don't know what would cause the unexpectedly small "local annex size".
+That should correspond to `du -hsc .git/annex/objects`; if it does then you
+seem to have fewer annexed objects than you expect for some reason.
+
+The behavior on sync sounds kind of like git commit is checking the whole
+contents of files into git, bypassing the annex. I don't know how that
+could happen, barring a misconfiguration, but it's at least the first thing
+to check. Check for gigabytes of data in .git/objects/ to see if that
+is the case. 
+
+If the above isn't the problem, can you see if the files in the work tree
+have a link count of 2? For example:
+
+	$ ls -l
+	-rw-r--r--  2 joey joey     30 Mar 14 12:49 foo
+	            ^
+
+If you don't see link count of 2, something has caused the annex.thin not
+to take effect. One possibility would be if the `git annex sync` merged in
+changes that moved a lot of files around. When that happens, git checks out
+the updated work tree, and git-annex currently is not able to preserve
+annex.thin in that case.
+"""]]