From f1ed19b454952d8b54ec2b629cad0fe7bbf8d185 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 27 Oct 2013 21:19:45 +0000 Subject: Added a comment --- .../comment_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 000000000..9d457a9d2 --- /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.) +"""]] -- cgit v1.2.3 From 6194eeec9fbb3c1a4b6033cc19e00dfa3f28732e Mon Sep 17 00:00:00 2001 From: RaspberryPie Date: Sun, 27 Oct 2013 22:07:32 +0000 Subject: --- 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 000000000..7dcef8693 --- /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? -- cgit v1.2.3 From 906f9c3acfe55afbdaad8d0afe7098e1033c0621 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: Added a comment: still cannot push when remote has renames --- ...ent_2_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 000000000..8b4ff46a4 --- /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 ? +"""]] -- cgit v1.2.3 From ea53cf7f760a27119e7c2c04fcbfe2101b5ef754 Mon Sep 17 00:00:00 2001 From: lorenzo Date: Sun, 27 Oct 2013 23:55:06 +0000 Subject: Added a comment: Running Debian squeeze binaries on libc 2.5 based NAS --- ...nt_14_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 000000000..e32cd97d5 --- /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]] + +"""]] -- cgit v1.2.3 From 0fd323271a895e8731821e2060f97fabca25a2fe Mon Sep 17 00:00:00 2001 From: lorenzo Date: Sun, 27 Oct 2013 23:56:26 +0000 Subject: Added a comment: Running Debian squeeze binaries on libc 2.5 based NAS --- ...nt_15_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 000000000..c3edf99e2 --- /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]] +"""]] -- cgit v1.2.3 From d0a74c62ea1494af214c6c57d0c596cca0b30c95 Mon Sep 17 00:00:00 2001 From: lorenzo Date: Sun, 27 Oct 2013 23:56:44 +0000 Subject: removed --- ...nt_14_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 e32cd97d5..000000000 --- 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]] - -"""]] -- cgit v1.2.3 From 23e249d5883b7a47ffed9cca23c810ee97bbfcfd 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: --- 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 000000000..0c67d1629 --- /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. -- cgit v1.2.3 From c8ffd6b4b3272bc427b84646f85e8fd828e825e4 Mon Sep 17 00:00:00 2001 From: "http://jspk.clavid.com/" Date: Mon, 28 Oct 2013 09:36:19 +0000 Subject: 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 000000000..81d6b35a3 --- /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. +"""]] -- cgit v1.2.3