From 2669c3ed9756e36e52a6ddb93cc96803347e1a15 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawniXLhO9mLn-7EDfawdENZ2fQwlGy5w_oc" Date: Tue, 12 Mar 2013 06:32:57 +0000 Subject: [PATCH 1/9] Added a comment: unrecognized command --- ...ent_11_f2775a151ed50caba27057bd9c38bae2._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment diff --git a/doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment b/doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment new file mode 100644 index 0000000000..9768300dc6 --- /dev/null +++ b/doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawniXLhO9mLn-7EDfawdENZ2fQwlGy5w_oc" + nickname="Michał" + subject="unrecognized command" + date="2013-03-12T06:32:56Z" + content=""" +Thanks Matthias, I fought with this as well, this was the tip I needed to move on. I'm using the Linux standalone, and I had 2 issues getting everything to work without getting git-annex-shell errors. + +1. The autoinstalled wrapper could not be found, I had to comment the \"Ubuntu exit\" line and add the $HOME/.ssh to path to get rid of \"command not found\" +2. Had to modify the wrapper by replacing the \"$SSH_ORIGINAL_COMMAND\" by \"$@\" to get rid of \"fatal: unrecognized command ''\" + + +"""]] From 1d0567292967704d31447eb9021cf32fe85dc939 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:16:19 +0000 Subject: [PATCH 2/9] --- .../Assistant_dropping_from_backup_repo.mdwn | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/Assistant_dropping_from_backup_repo.mdwn diff --git a/doc/bugs/Assistant_dropping_from_backup_repo.mdwn b/doc/bugs/Assistant_dropping_from_backup_repo.mdwn new file mode 100644 index 0000000000..5e83b17ee5 --- /dev/null +++ b/doc/bugs/Assistant_dropping_from_backup_repo.mdwn @@ -0,0 +1,23 @@ +Setup: + +* fresh install of Debian Wheezy on machines A & B, git-annex 4.20130227 pulled in from unstable +* clone repository onto A & B and pair them (manual SSH key setup), and plug USB backup drive, U, into A +* U has repository group `backup` and preferred content string `standard` +* A & B have repository group `client` and preferred content string `present or include=subdir1/* or ...` + +Steps: + +* Add a new file to B +* On B, `git annex copy -t A newfile` + +Expected: + +* File arrives at B and is copied to U by B's assistant +* File remains on B + +Actual: + +* File arrives on B and is copied to U +* File is dropped from B + +Seems like a resurfacing of [[forum/assistant_overzealously_moving_stuff_to_other_repos]]? Thanks. From 5eed66579f4c88b4f6538eef204b655fa98eb492 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:25:30 +0000 Subject: [PATCH 3/9] --- .../Partial_direct__47__indirect_repo.mdwn | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bugs/Partial_direct__47__indirect_repo.mdwn diff --git a/doc/bugs/Partial_direct__47__indirect_repo.mdwn b/doc/bugs/Partial_direct__47__indirect_repo.mdwn new file mode 100644 index 0000000000..c0ff685222 --- /dev/null +++ b/doc/bugs/Partial_direct__47__indirect_repo.mdwn @@ -0,0 +1,22 @@ +Setup: + +* Fresh install of Debian Wheezy on machines A & B, git-annex 4.20130227 pulled in from unstable +* On both machines, clone old repository which contains both annexed files and a three small files checked straight into git + +Steps: + +* On both machines, use webapp to create `~/.config/git-annex/autostart` by just firing it up and typing in location of existing repository +* Move a new file into B's annex, in a subdirectory that is preferred on both A & B + +Expected: + +* The new file is copied over to A and everything remains in indirect mode +* Three files checked straight into git remain checked straight into git (see below for why this is a variant on [[bugs/Switching_between_direct_and_indirect_stomps_on___39__regular__39___git_files/]]) + +Actual: + +* New file copied over but seems to be in direct mode, while all the other content that is present is still symlinked +* Files checked into git converted to direct mode files too (can tell this has happened by following step:) +* Typing `git annex indirect` on A & B shows conversion of precisely four files (three files originally checked into git and new file added to B) back to indirect + +Thanks. From 16a8e61156ba18a741a9efdfed5aeb493b1cd26b Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:25:47 +0000 Subject: [PATCH 4/9] --- doc/bugs/Partial_direct__47__indirect_repo.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bugs/Partial_direct__47__indirect_repo.mdwn b/doc/bugs/Partial_direct__47__indirect_repo.mdwn index c0ff685222..8c6ebf2eee 100644 --- a/doc/bugs/Partial_direct__47__indirect_repo.mdwn +++ b/doc/bugs/Partial_direct__47__indirect_repo.mdwn @@ -17,6 +17,6 @@ Actual: * New file copied over but seems to be in direct mode, while all the other content that is present is still symlinked * Files checked into git converted to direct mode files too (can tell this has happened by following step:) -* Typing `git annex indirect` on A & B shows conversion of precisely four files (three files originally checked into git and new file added to B) back to indirect +* Typing `git annex indirect` on A & B shows conversion of precisely four files (three files originally checked into git and new file added to B ) back to indirect Thanks. From 4076d3f398ac54176cad98a24c58a61676b079f6 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:26:48 +0000 Subject: [PATCH 5/9] rename bugs/Assistant_dropping_from_backup_repo.mdwn to bugs/Assistant_dropping_files_it_has_just_transferred_elsewhere_again.mdwn --- ...t_dropping_files_it_has_just_transferred_elsewhere_again.mdwn} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename doc/bugs/{Assistant_dropping_from_backup_repo.mdwn => Assistant_dropping_files_it_has_just_transferred_elsewhere_again.mdwn} (100%) diff --git a/doc/bugs/Assistant_dropping_from_backup_repo.mdwn b/doc/bugs/Assistant_dropping_files_it_has_just_transferred_elsewhere_again.mdwn similarity index 100% rename from doc/bugs/Assistant_dropping_from_backup_repo.mdwn rename to doc/bugs/Assistant_dropping_files_it_has_just_transferred_elsewhere_again.mdwn From 8c3ce000d6a5aaf66a92f8ce58e061b4b2531a4a Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:31:47 +0000 Subject: [PATCH 6/9] --- .../Assistant_dropping_from_backup_repo.mdwn | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/Assistant_dropping_from_backup_repo.mdwn diff --git a/doc/bugs/Assistant_dropping_from_backup_repo.mdwn b/doc/bugs/Assistant_dropping_from_backup_repo.mdwn new file mode 100644 index 0000000000..828105aa2f --- /dev/null +++ b/doc/bugs/Assistant_dropping_from_backup_repo.mdwn @@ -0,0 +1,23 @@ +Setup: + +* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable + +Steps: + +* clone existing repository and activate assistant +* Have USB drive, U, with repository group `backup` and preferred content string `standard` + +Expected: + +* Assistant never ever tries to drop anything from U + +Actual: + +* Assistant immediately tries to drop files from U; fortunately I didn't have the USB drive plugged in +* Changing the preferred content string of U to `present or include=*` stops the dropping, but this was never required before + +Additional information: + +* The files that the Assistant started trying to drop were, I believe, the first (alphabetically) files in my repository to contain non-ascii characters in their file names (some French accented letters) + +Thanks. From e5df2af5744d063eec907ef281aa82ca99552b8b Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:33:17 +0000 Subject: [PATCH 7/9] Added a comment --- .../comment_2_fdcaf507e14c995636dd93a41e488df3._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment diff --git a/doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment b/doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment new file mode 100644 index 0000000000..a20fc7e761 --- /dev/null +++ b/doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="spwhitton" + ip="82.36.235.9" + subject="comment 2" + date="2013-03-12T09:33:17Z" + content=""" +The use case this is really good for, that XMPP push can't help with, is for when two paired machines are almost never both turned on at once. +"""]] From 7bb6e6e305704c2749a8f329267367d00d450fad Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:34:08 +0000 Subject: [PATCH 8/9] Added a comment --- .../comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment new file mode 100644 index 0000000000..09b9d8564f --- /dev/null +++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="spwhitton" + ip="82.36.235.9" + subject="comment 2" + date="2013-03-12T09:34:08Z" + content=""" +Thanks for the tip--I will definitely make another attempt at some point. +"""]] From 16da0f7ba29d4846a81ff0801e6ff85cad85eb29 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Tue, 12 Mar 2013 09:42:04 +0000 Subject: [PATCH 9/9] --- ...e_cannot_be_reactivated_by_the_webapp.mdwn | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn diff --git a/doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn b/doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn new file mode 100644 index 0000000000..605027f28d --- /dev/null +++ b/doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn @@ -0,0 +1,28 @@ +Setup: + +* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable +* clone existing repository and activate assistant +* repository has encrypted rsync remote originally setup with the name `metaarray` +* this remote was renamed to `ma` a long time ago, using the webapp +* had to perform this rename on each client + +Steps: + +* attempt to reactivate special remote using webapp repositories page, on reinstalled machine + +Expected: + +* special remote starts working +* renaming special remotes ought to survive clones + +Actual: + +* firstly, special remote activation page has blank hostname box and the hostname of the machine is in the username box +* form gives error "cannot change encryption type of existing remote" + +Workaround: + +* execute `git annex initremote metaarray` +* rename `metaarray` to `ma` again using the webapp + +Perhaps the renaming of the remote not surviving clones is unavoidable, but the webapp should be able to cope with the situation. Thanks.