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

6 files changed, 32 insertions, 2 deletions

diff --git a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn b/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
index a9e822d46..5afd3d31a 100644
--- a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
+++ b/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
@@ -101,4 +101,4 @@ Everything up-to-date
 """]]
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
-It seems to work really well on v5, but the file "corruption" is difficult to recover from.
+It seems to work really well on v5, but the v6 file "corruption" is difficult to recover from.
diff --git a/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment
new file mode 100644
index 000000000..3e1f171bd
--- /dev/null
+++ b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-05-12T06:52:50Z"
+ content="""
+This didn't work, because syncing was disabled before trying to delete the remote. Deleting involves putting the remote in the unwanted group and through active syncing remove all the content from it, before deleting it fully. The assistant should be able to handle starting deletion processes, even when synching is disabled. At least there should be a dialogue telling the user that synching is disabled and therefore the deletion process will not start.
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment
new file mode 100644
index 000000000..d4838d098
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 8"
+ date="2016-05-11T20:32:54Z"
+ content="""
+I set `git config remote.s3.annex-verify false`, and `ignore-mdc-error` in my `gpg.conf`. That allowed me to succesfully download the files. From there I was able to recover the bulk of the files in the archives. Thanks!
+
+Any ideas what caused the files to become corrupted in the first place? Is there anything I can do different when adding new files and copying them to the s3 special remote to prevent corruption?
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment
new file mode 100644
index 000000000..cb94b7225
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-05-12T06:57:15Z"
+ content="""
+As it turns out, even this doesn't work hundred percent of the time, which is terrible! I rely on stoping the assistant once to at least three times a day to be able to skype without having to worry about my upload. My connection simply cannot handle both things at the same time. So what should I do?
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment
new file mode 100644
index 000000000..294c5042f
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 2"
+ date="2016-05-12T07:49:33Z"
+ content="""
+I finally could reliably prevent git annex from fuzzinh with my skype sessions by using [little snitch](http://obdev.at/products/littlesnitch). I created a profile that prevents outgoing connections from git annex etc. and now I can leave git annex assistant running in the background. This is at the same time a good and a terrible solution, since I now need to run commercial software to prevent git annex from dictating how well my skype sessions are going and at the same time not relying on killing git annex processes by hand which in turn leads to git annex wanting repair itself all the time.
+"""]]
diff --git a/doc/forum/performance_for_FTP_site_mirroring.mdwn b/doc/forum/performance_for_FTP_site_mirroring.mdwn
index a76973a75..552b2670e 100644
--- a/doc/forum/performance_for_FTP_site_mirroring.mdwn
+++ b/doc/forum/performance_for_FTP_site_mirroring.mdwn
@@ -16,7 +16,7 @@ Here are my questions:
 
 5. Another reason why I appear to be forced to use "unlocked" mode is that, as part of the mirroring, the directory permissions are set to match the site, which are not writable.  git-annex appears to be unable to move the files that are inside of directories without write permissions.  Note that I am the owner of the local files/directories, and lftp happily adds and modifies files insides of these unwritable directories just fine, presumably by temporarily changing the permissions.  Is this correct?  Should I submit a feature request here?
 
-5. Although I am using WORM and unlocked mode, I found the initial "git add" and "git commit" of the 10K / 30GB of files to be pretty slow.  It takes on the order of 30 minutes for the add and an hour for the commit.  I didn't see a ton of either CPU or I/O activity.  Is this to be expected?  I would have hoped that the WORM backend prevents git from needing to actually read the files for a checksum.  (I'm hopeful that with the WORM backend, subsequent add and commits will be a lot faster.)
+5. Although I am using WORM and unlocked mode, I found the initial "git add" and "git commit" of the 10K / 30GB of files to be pretty slow.  It takes on the order of 30 minutes for the add and an hour for the commit.  I didn't see a ton of either CPU or I/O activity.  A subsequent update of about 600 files is taking a long time to add (running 'git add -A'.)  I assume commit time will also be long.  Is this to be expected?  I would have hoped that the WORM backend prevents git from needing to actually read the files for a checksum.
 
 6. I understand that "thin = false" will lead to data duplication.  I assume this will make the initial commits slower.  Are there other performance implications of changing the thin setting?