From 633757d1615384e1f6ef142cec65601e69a186ce Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 27 Oct 2013 21:19:45 +0000 Subject: [PATCH 1/8] Added a comment --- ...ent_1_70200f871b9df49261f32752a6bb0e67._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment diff --git a/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment b/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment new file mode 100644 index 0000000000..9d457a9d2d --- /dev/null +++ b/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.47" + subject="comment 1" + date="2013-10-27T21:19:45Z" + content=""" +When you create an encrypted rsync repository using the webapp like that, its encryption key is stored in your git repository, using the [[shared encryption scheme|encryption#index2h2]]. No gpg key needs to be used to decrypt files from the rsync repository; anyone with a clone of your git repository can do so. This has its plusses and its minuses; the webapp picks that type of encryption because it's easy to use. + +So, the answer is to just make a clone of your repository on the other machine, and then you can use it. There are lots of ways to do that; if you stay in the webapp, go to Add Another Repisitory and any of the \"Share with your other devices\", \"Share with a friend\", or \"Local computer\" options are easy ways to do it. + +---- + +Now, if you had, manually, set up a rsync repository encrypted with the [[hybrid encryption key scheme|encryption#index1h2]], to access it from another computer with clone of the repository you would need to have a gpg key that has been given access to the repository. So you would either copy your gpg secret key to the other computer, or if you don't want to trust that other computer with the your main gpg key, you could make another gpg secret key for that computer, and add that key as one of the keys that can access the encrypted repository. (Or, if the computer belonged to a friend, you could just get their gpg key, and add it.) +"""]] From a56da6dd50935758f6b53c32ed55f2066ce9a0f5 Mon Sep 17 00:00:00 2001 From: RaspberryPie Date: Sun, 27 Oct 2013 22:07:32 +0000 Subject: [PATCH 2/8] --- doc/forum/known_and_local_annex_keys.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/forum/known_and_local_annex_keys.mdwn diff --git a/doc/forum/known_and_local_annex_keys.mdwn b/doc/forum/known_and_local_annex_keys.mdwn new file mode 100644 index 0000000000..7dcef8693e --- /dev/null +++ b/doc/forum/known_and_local_annex_keys.mdwn @@ -0,0 +1,14 @@ +I have a direct repository with the assistant running (v4.20131002). The repo is in the backup group and should be grabbing every known annex file. Yet `git annex status` says: + + local annex keys: 1386 + local annex size: 94.53 gigabytes + known annex keys: 1387 + known annex size: 94.53 gigabytes + +As you can seem there is one more known annex key than there are local ones. Neither `git annex get` nor `git annex sync` changes the numbers. According to `tree` the repo dir contains exactly 1387 files, which means that the missing file must exist on disk. + +1) How do I find out which is the file in question? How do I get it synchronized? + +Yesterday there were 1376 known annex keys. Today there are 1387. For some reason the number of keys went up by 11, and I would like to know how and why. The log suggests that a couple of files have been added from inside the repo directory, but I am positive that these files already existed in the annex directory yesterday, and that I ran `git annex sync` manually without the number of local and/or known keys going up. + +2) Why weren't the files synced before? Is there a way to find out whether they were or were not part of the annex yesterday - maybe list all files sorted by the date they were added? From 92e374b51ad0858897828da6fc051e7dd0cb4beb Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" Date: Sun, 27 Oct 2013 23:06:03 +0000 Subject: [PATCH 3/8] Added a comment: still cannot push when remote has renames --- ..._8c86dfc99f0b9040402c9d746decda53._comment | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment diff --git a/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment new file mode 100644 index 0000000000..8b4ff46a40 --- /dev/null +++ b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment @@ -0,0 +1,41 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" + nickname="Michele" + subject="still cannot push when remote has renames" + date="2013-10-27T23:06:03Z" + content=""" +now, I went again through docs, and i realized how stupid was issuing a git pull on a direct repo. thanks for your patience. + +but, i double checked the configuration, I assume \"receive.denyNonFastForwards\" is false by default, but anyway I set it up explicitely so that now my git config (on the linux indirect repo - with respect to my previous example, I got rid of the \"extra\" bare repo in the middle) shows: + + $ git config --list + user.email=m@g.com + user.name=michele + core.repositoryformatversion=0 + core.filemode=true + core.bare=false + core.logallrefupdates=true + annex.uuid=d084e0fd-95a7-4c98-a206-fbf2c85b779d + annex.version=3 + receive.denynonfastforwards=false + +still I am receiving the push refusal: + + M:\win>git annex sync + commit + ok + pull origin + ok + push origin + To ssh://michele@home/home/michele/casa + ! [rejected] master -> synced/master (non-fast-forward) + error: failed to push some refs to 'ssh://michele@home/home/michele/casa' + hint: Updates were rejected because a pushed branch tip is behind its remote + hint: counterpart. Check out this branch and merge the remote changes + hint: (e.g. 'git pull') before pushing again. + hint: See the 'Note about fast-forwards' in 'git push --help' for details. + failed + git-annex: sync: 1 failed + +Same happens with a bare repository in the middle. BTW: the windows \"client\" repository is behind NAT, so that the linux indirect doesn't actively sync against it: could that be source of the problem ? +"""]] From 3cc3692d3dcd3b8f575f02d137f5b5f118577bee Mon Sep 17 00:00:00 2001 From: lorenzo Date: Sun, 27 Oct 2013 23:55:06 +0000 Subject: [PATCH 4/8] Added a comment: Running Debian squeeze binaries on libc 2.5 based NAS --- ..._c92d25fb3ae3b325584c78d6b11c1fc3._comment | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment diff --git a/doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment b/doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment new file mode 100644 index 0000000000..e32cd97d58 --- /dev/null +++ b/doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment @@ -0,0 +1,31 @@ +[[!comment format=mdwn + username="lorenzo" + ip="84.75.27.69" + subject="Running Debian squeeze binaries on libc 2.5 based NAS" + date="2013-10-27T23:55:05Z" + content=""" +Following the suggestions in this page I tried to run the binaries that debian provides on my Lacie NetworkSpace which is another one of these NAS devices with old libc. After uploading the binaries and required libraries and using `LD_LIBRARY_PATH` to force the loader to use the version I uploaded of the libraries I was still having a segfault (similar to what Franck was experiencing) while running git-annex in a chroot was working. + +It turns out that it is possible to solve the problem without having to use chroot by not loading the binary directly but by substituting it with a script that calls the correct `ld-linux.so.3`. Assume you have uncompressed the files from the deb packages in `/opt/git-annex`. + +First create a directory `/opt/git-annex/usr/bin/git-annex.exec` and copy the executable `/opt/git-annex/usr/bin/git-annex` there. + +Then create script `/opt/git-annex/usr/bin/git-annex` with the following contents: + + #!/bin/bash + + PREFIX=/opt/git-annex + + export GCONV_PATH=$PREFIX/usr/lib/gconv + + exec $PREFIX/lib/ld-linux.so.3 --library-path $PREFIX/lib/:$PREFIX/usr/lib/ $PREFIX/usr/bin/git-annex.exec/git-annex \"$@\" + +The `GCONV_PATH` setting is important to prevent the app from failing with the message: + + git-annex.exec: mkTextEncoding: invalid argument (Invalid argument) + +The original executable is moved to a different directory instead of being simply renamed to make sure that `$0` is correct when the executable starts. The parameter for the linker `--library-path` is used instead of the environment variable `LD_LIBRARY_PATH` to make sure that the programs exec'ed by git-annex do not have the variable set. + +Some more info about the approach: [[http://www.novell.com/coolsolutions/feature/11775.html]] + +"""]] From 3ab515722db13ad275ba7943550bf8976dcc7d36 Mon Sep 17 00:00:00 2001 From: lorenzo Date: Sun, 27 Oct 2013 23:56:26 +0000 Subject: [PATCH 5/8] Added a comment: Running Debian squeeze binaries on libc 2.5 based NAS --- ..._9525cd0d75ff4c15182d10a855774b69._comment | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment diff --git a/doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment b/doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment new file mode 100644 index 0000000000..c3edf99e25 --- /dev/null +++ b/doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment @@ -0,0 +1,30 @@ +[[!comment format=mdwn + username="lorenzo" + ip="84.75.27.69" + subject="Running Debian squeeze binaries on libc 2.5 based NAS" + date="2013-10-27T23:56:26Z" + content=""" +Following the suggestions in this page I tried to run the binaries that debian provides on my Lacie NetworkSpace which is another one of these NAS devices with old libc. After uploading the binaries and required libraries and using `LD_LIBRARY_PATH` to force the loader to use the version I uploaded of the libraries I was still having a segfault (similar to what Franck was experiencing) while running git-annex in a chroot was working. + +It turns out that it is possible to solve the problem without having to use chroot by not loading the binary directly but by substituting it with a script that calls the correct `ld-linux.so.3`. Assume you have uncompressed the files from the deb packages in `/opt/git-annex`. + +First create a directory `/opt/git-annex/usr/bin/git-annex.exec` and copy the executable `/opt/git-annex/usr/bin/git-annex` there. + +Then create script `/opt/git-annex/usr/bin/git-annex` with the following contents: + + #!/bin/bash + + PREFIX=/opt/git-annex + + export GCONV_PATH=$PREFIX/usr/lib/gconv + + exec $PREFIX/lib/ld-linux.so.3 --library-path $PREFIX/lib/:$PREFIX/usr/lib/ $PREFIX/usr/bin/git-annex.exec/git-annex \"$@\" + +The `GCONV_PATH` setting is important to prevent the app from failing with the message: + + git-annex.exec: mkTextEncoding: invalid argument (Invalid argument) + +The original executable is moved to a different directory instead of being simply renamed to make sure that `$0` is correct when the executable starts. The parameter for the linker `--library-path` is used instead of the environment variable `LD_LIBRARY_PATH` to make sure that the programs exec'ed by git-annex do not have the variable set. + +Some more info about the approach: [[http://www.novell.com/coolsolutions/feature/11775.html]] +"""]] From ca77441eeb0ce8cc3a3ca601e833d68ea8665356 Mon Sep 17 00:00:00 2001 From: lorenzo Date: Sun, 27 Oct 2013 23:56:44 +0000 Subject: [PATCH 6/8] removed --- ..._c92d25fb3ae3b325584c78d6b11c1fc3._comment | 31 ------------------- 1 file changed, 31 deletions(-) delete mode 100644 doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment diff --git a/doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment b/doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment deleted file mode 100644 index e32cd97d58..0000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_14_c92d25fb3ae3b325584c78d6b11c1fc3._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="lorenzo" - ip="84.75.27.69" - subject="Running Debian squeeze binaries on libc 2.5 based NAS" - date="2013-10-27T23:55:05Z" - content=""" -Following the suggestions in this page I tried to run the binaries that debian provides on my Lacie NetworkSpace which is another one of these NAS devices with old libc. After uploading the binaries and required libraries and using `LD_LIBRARY_PATH` to force the loader to use the version I uploaded of the libraries I was still having a segfault (similar to what Franck was experiencing) while running git-annex in a chroot was working. - -It turns out that it is possible to solve the problem without having to use chroot by not loading the binary directly but by substituting it with a script that calls the correct `ld-linux.so.3`. Assume you have uncompressed the files from the deb packages in `/opt/git-annex`. - -First create a directory `/opt/git-annex/usr/bin/git-annex.exec` and copy the executable `/opt/git-annex/usr/bin/git-annex` there. - -Then create script `/opt/git-annex/usr/bin/git-annex` with the following contents: - - #!/bin/bash - - PREFIX=/opt/git-annex - - export GCONV_PATH=$PREFIX/usr/lib/gconv - - exec $PREFIX/lib/ld-linux.so.3 --library-path $PREFIX/lib/:$PREFIX/usr/lib/ $PREFIX/usr/bin/git-annex.exec/git-annex \"$@\" - -The `GCONV_PATH` setting is important to prevent the app from failing with the message: - - git-annex.exec: mkTextEncoding: invalid argument (Invalid argument) - -The original executable is moved to a different directory instead of being simply renamed to make sure that `$0` is correct when the executable starts. The parameter for the linker `--library-path` is used instead of the environment variable `LD_LIBRARY_PATH` to make sure that the programs exec'ed by git-annex do not have the variable set. - -Some more info about the approach: [[http://www.novell.com/coolsolutions/feature/11775.html]] - -"""]] From d245201e6dc7ef98b88b94bdbc92e72f1b768b47 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnWwEEA3CurHkBjIYaJsJzFc4jtY2SCkrQ" Date: Mon, 28 Oct 2013 08:38:06 +0000 Subject: [PATCH 7/8] --- doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn diff --git a/doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn b/doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn new file mode 100644 index 0000000000..0c67d16296 --- /dev/null +++ b/doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn @@ -0,0 +1,3 @@ +It'd be useful to be able to see what `git annex drop` would do *before* asking it to drop any files. + +For example, I just set up my preferred contents expressions, and I don't know if I got them right. Before dropping anything from this repo, it'd be nice to check what would happen. I know git annex drop will only drop files that are above their minimum numcopies, but I'd still like to avoid heavyweight copying in case I got my preferred contents expressions wrong. From 39dc2444e38bcee5d1e777e01cb1f6cc46555764 Mon Sep 17 00:00:00 2001 From: "http://jspk.clavid.com/" Date: Mon, 28 Oct 2013 09:36:19 +0000 Subject: [PATCH 8/8] Added a comment --- .../comment_2_8d09cc0e06548c4ebde7956edd1b5d85._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_2_8d09cc0e06548c4ebde7956edd1b5d85._comment diff --git a/doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_2_8d09cc0e06548c4ebde7956edd1b5d85._comment b/doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_2_8d09cc0e06548c4ebde7956edd1b5d85._comment new file mode 100644 index 0000000000..81d6b35a39 --- /dev/null +++ b/doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_2_8d09cc0e06548c4ebde7956edd1b5d85._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://jspk.clavid.com/" + nickname="flabbergast" + subject="comment 2" + date="2013-10-28T09:36:19Z" + content=""" +Thanks! I've checked now and the problem is gone. +"""]]