Added a comment

1 files changed, 18 insertions, 0 deletions

diff --git a/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment b/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment
new file mode 100644
index 000000000..80a047025
--- /dev/null
+++ b/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-05-19T16:39:44Z"
+ content="""
+So there are a lot of uploads attempts being made (and apparently failing), and a lot of zombie git-annex processes are building up as children of the git-annex transferkeys process. That isolates the problem some.
+
+The repeated \"(gpg)\" is an interesting clue, since normally git-annex only runs gpg once, to unlock an encrypted special remote's encryption key, and then should retain the key, cached in memory. I was able to reproduce this part of the bug (but not the zombie processes) when I purposfully broke the bup special remote by making it throw an error when it was supposed to run bup to send a file. That defeats the caching, since the state, including the cache, is thrown away when there's an exception. Working on a fix for that..
+
+That doesn't explain what's actually causing the problem for you, but it does certianly suggest the bup special remote code is failing in some unusual way. What happens if rather than starting the assistant, you use git-annex manually to send files to the remote? Run:
+
+<pre>
+git annex copy --to ffe41272-608e-43c4-8f35-e9cd63087892 --debug
+</pre>
+
+(You may want to give it the name of just 1 file to send.)
+"""]]