1 files changed, 27 insertions, 0 deletions
diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_1_6f4179fe22d85b4a51e4aad60c4ff00d._comment b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_1_6f4179fe22d85b4a51e4aad60c4ff00d._comment
new file mode 100644
index 000000000..e22ea1d93
--- /dev/null
+++ b/doc/bugs/Massive_git_add_produces_sqlite_crashes/comment_1_6f4179fe22d85b4a51e4aad60c4ff00d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-11-07T17:48:28Z"
+ content="""
+There have been several bug reports with that same error message
+and different causes (permissions problems; filesystems on which sqlite
+doesn't work etc). So all that I know from the error is something went
+wrong with the sqlite database, which causes queries of it to fail.
+
+Using the linux version of git-annex on Winows via the (misleadingly named)
+"bash for windows" is pretty unusual. I have never seen it work; Microsoft
+were still adding missing linux system calls to their emulation layer the
+last time I tried it. It's quite possible that there remains a bug in that
+emulation layer, that prevents sqlite from working, or makes it unreliable,
+etc. I cannot reproduce the problem running git-annex on Linux.
+
+Note that since it's a v6 repository, running `git add` actually adds the
+files to git-annex. `git add` unfortunately runs `git-annex smudge` once
+per file. As you note, this is slow; this is one of the several reasons
+documented in [[todo/smudge]] why v6 mode is still considered experimental;
+and it will need changes in git to improve the speed).
+
+It would be useful to know if it's failing on the first file, 
+or if several files get processed ok before it begins to fail.
+You could set `GIT_TRACE=1` in the environment to find out.
+"""]]