diff options
6 files changed, 110 insertions, 0 deletions
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. +"""]] 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.) +"""]] 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? 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 ? +"""]] 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]] +"""]] 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. |