Merge branch 'master' of ssh://git-annex.branchable.com

5 files changed, 79 insertions, 0 deletions

diff --git a/doc/bugs/Small_archive_behaving_like_archive/comment_1_718dc246cbbbeae04436fa033011ab12._comment b/doc/bugs/Small_archive_behaving_like_archive/comment_1_718dc246cbbbeae04436fa033011ab12._comment
new file mode 100644
index 000000000..dd509cdde
--- /dev/null
+++ b/doc/bugs/Small_archive_behaving_like_archive/comment_1_718dc246cbbbeae04436fa033011ab12._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-06T21:09:00Z"
+ content="""
+I have tested smallarchive and do not see any bug with its operation. Files not in an `archive` directory are not sent to the smallarchive repository. Files in `archive` directories are, unless they have already been sent to some other archive repository.
+
+There has, however, been a recent change that could have led you to see a change in behavior, though not one that is really a bug:
+Now smallarchive repositories will accept any content if it's only located on repositories that are untrusted or dead. So for example if your main client repo is for some reason marked as untrusted, the glacier repo would assume it's going away, and accept content from it.
+
+If that's not the explanation, you will need to provide more details..
+"""]]
diff --git a/doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment b/doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment
new file mode 100644
index 000000000..ec50b58c5
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 10"
+ date="2013-05-06T16:54:36Z"
+ content="""
+My estimate was indeed slightly optimistic. While I did not run the whole import, it did run slower for the later batches of files. As far as I can see, that slowdown is just because git gets slower as it has more files. So nothing I can do about it. git-annex is now scaling well itself, though.
+
+Re checksumming on startup: There was a bug that caused the assistant to re-checksum all direct mode files on startup. This bug was fixed in version 4.20130417. If you're using that version and still see it re-checksumming files, please file a new bug report about it, as this is not intended behavior.
+
+You seem to be saying that the assistant is failing to add some files, and then when stopped and restarted it finds and adds them. I don't quite know how that would happen. If you can provide a test case that I can use to reproduce that behavior, I will try to debug it.
+"""]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment
new file mode 100644
index 000000000..d16392542
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2013-05-06T16:52:07Z"
+ content="""
+It's possible, even likely, that there were indeed more directories and I didn't notice because they were hidden and I just looked at them with a vanilla \"ls\" command with no flags like \"-a\".
+
+So it's probably exactly what you're thinking --t here was something going on, a transfer queued or something, that I didn't realize was happening and I removed it and it went and created the directory as if it were there.  
+"""]]
diff --git a/doc/bugs/git_annex_assistant_--autostart_failed/comment_3_bfd646f69946a5fe926b270cf94f87cb._comment b/doc/bugs/git_annex_assistant_--autostart_failed/comment_3_bfd646f69946a5fe926b270cf94f87cb._comment
new file mode 100644
index 000000000..e53a3115d
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_--autostart_failed/comment_3_bfd646f69946a5fe926b270cf94f87cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn26WQjIP5fnMgQF_L_k3Q3UrR5v8mjRTY"
+ nickname="Ellis"
+ subject="comment 3"
+ date="2013-05-06T18:24:35Z"
+ content="""
+I just had the exact same issue.  Thanks for posting the fix.
+"""]]
diff --git a/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment b/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment
new file mode 100644
index 000000000..43211bdd8
--- /dev/null
+++ b/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-06T17:09:58Z"
+ content="""
+What version of gnupg do you have installed?
+
+<pre>
+gpg: block_filter 0x946320: read error (size=12864,a->size=12864)
+gpg: [don't know]: invalid packet (ctb=68)
+gpg: [don't know]: invalid packet (ctb=21)
+gpg: mdc_packet with invalid encoding
+gpg: decryption failed: invalid packet
+gpg: [don't know]: invalid packet (ctb=00)
+gpg: block_filter: pending bytes!
+</pre>
+
+I don't see how git-annex can possibly guard against gpg behaving this way when given bad data. So the best thing to do would be to get a test case file that causes gpg to behave this way, and then I could file a bug on gpg and get it fixed to immediately exit.
+
+I tried to reproduce this by encrypting a 1 mb file with gpg. This yeilded a 1.1 mb file. I then truncated it back to 1 mb, and tried to decrypt it.
+
+[[!format sh \"\"\"
+joey@gnu:~>gpg --decrypt me2.gpg > x
+gpg: encrypted with 1 passphrase
+gpg: block_filter 0x9d6fda0: read error (size=15680,a->size=15680)
+gpg: Problem reading source (8570 bytes remaining)
+gpg: handle plaintext failed: file read error
+gpg: mdc_packet with invalid encoding
+gpg: decryption failed: invalid packet
+gpg: block_filter: pending bytes!
+zsh: exit 2     gpg --decrypt 
+\"\"\"]]
+
+gpg exited immediately on error, which is what it should do. So it doesn't seem likely I can guess at a test case file that causes gpg to behave this way. You will need to provide one for me to help.
+"""]]