diff options
Diffstat (limited to 'doc')
85 files changed, 649 insertions, 52 deletions
diff --git a/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment new file mode 100644 index 000000000..17ac4c275 --- /dev/null +++ b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 8" + date="2014-08-12T18:00:46Z" + content=""" +Ævar, you can use `git annex add --backend=SHA256` to temporarily override the backend. +"""]] diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment new file mode 100644 index 000000000..a4f56553c --- /dev/null +++ b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-15T17:52:57Z" + content=""" +I'm afraid all I can do to help with this is to say that the git-annex Android app does not do anything I know of to prevent running the programs, such as git, that are included in it. If your user cannot access them, it must be your OS configuration preventing it. +"""]] diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn new file mode 100644 index 000000000..2b3cf3f2f --- /dev/null +++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn @@ -0,0 +1,23 @@ +This is a follow-up to [this +qbug](http://git-annex.branchable.com/bugs/WORM_keys_differ_depending_on_working_dir_during_add/). +Thank you for your fix there! However, if I understood correctly, you +indicated in your reply that the current fix completely removes the +relative path component from WORM keys. I gave some thought to this +and believe not having the relative path encoded inside WORM keys +makes key collisions (and accordingly data-loss) a very dire problem, +while they are not of practical concern if the relative path is +encoded. + +When relative paths are encoded within the key, a collision can only +occur when a file in the same directory is annexed twice within the +resolution of the mtime component inside the key (i.e., one second). +As such, unless one adds files automatically with a period of < 1s, +one can very much be certain that no collisions come up. + +Without relative paths, however, one could never be certain that +adding a file will not result in data-loss. + +Instead of just using the basename, WORM keys could be kept stable by +using the relative path and anchoring it to the root of the +repository. + diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_1_b37615636e685b60fab8ae1c4276d032._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_1_b37615636e685b60fab8ae1c4276d032._comment new file mode 100644 index 000000000..71164b0bd --- /dev/null +++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_1_b37615636e685b60fab8ae1c4276d032._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-15T17:32:15Z" + content=""" +I don't see much difference between (mtime, size, location) and (mtime, size) as far as entropy goes. Consider: A repository with all files in a single directory in the top level is going to have identical probabilities of collision either way. A less special case of a repository that typically has files added to it in a particular directory (\"inbox\", say), is again going to have identical probabilities of collision. + +If you're worried about such collisions, you should not be using WORM. I think that the documentation for it is pretty clear. + +If we really wanted to increase the entropy of worm, we could add a random number to the key, or perhaps the file's (original) inode number. +"""]] diff --git a/doc/bugs/Truncated_file_transferred_via_S3.mdwn b/doc/bugs/Truncated_file_transferred_via_S3.mdwn index 9261c8a05..b489f60d9 100644 --- a/doc/bugs/Truncated_file_transferred_via_S3.mdwn +++ b/doc/bugs/Truncated_file_transferred_via_S3.mdwn @@ -612,3 +612,6 @@ BST] XMPPClient: NetMessager stored Pushing "e57" (ReceivePackDone ExitSuccess) # End of transcript or log. """]] + +> Pretty sure this must have been due to Char8 truncation. So, +> [[fixed|done]]. diff --git a/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn b/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn index e41220114..9787ad5cc 100644 --- a/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn +++ b/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn @@ -55,3 +55,14 @@ $ readlink quux Linux 3.15.8 git-annex 5.20140716 + +> This was a bug. I suspect it got broken a while ago and I didn't noticed +> since I rarely use WORM and when I do it's almost always adding files +> in the current directory. [[fixed|done]] to take the filename only. +> +> I don't think it's a problem to have the subdirectory path in the +> existing WORM keys, other than the problems you note with this meaning +> a later add of the same file will generate a different key. So I have not +> done anything to try to fix up existing keys. (If this became a problem, +> I could add upgrade code to the WORM backend.) +> --[[Joey]] diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment new file mode 100644 index 000000000..a705f6855 --- /dev/null +++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlU0H3uyacCnqWxjSI_chHBlHu8TDIkTt0" + nickname="Matt" + subject="cannot connect via google apps domain" + date="2014-08-14T15:55:07Z" + content=""" +Having the same issue with our domain: zebradog.com SRV records are correctly specified (as defined here: https://support.google.com/a/answer/34143?hl=en) +"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn index 0d81c6778..c19db9727 100644 --- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn +++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn @@ -41,3 +41,5 @@ Similar issues and discussions: * [[forum/Cleaning_up_after_aborted_sync_in_direct_mode/]] * [[bugs/failure_to_return_to_indirect_mode_on_usb/]] * [[forum/git-status_typechange_in_direct_mode/]] + +[[!meta title="git annex lock --force deletes only copy of content after interrupted switch to direct mode"] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment new file mode 100644 index 000000000..4d7246eda --- /dev/null +++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T17:26:46Z" + content=""" +The way it's supposed to work is that `git annex direct` does not set the repository into direct mode until it's entirely done moving files around. So, if it is interrupted at any point, you are left with an indirect mode repository, with some unlocked files. Which can be put back to indirect by `git annex add`, or the conversion restarted with `git annex direct`. + +That seems to work in my tests; I can interrupt `git annex direct` and resume with `git annex direct` with a good result; `git annex add` reverts back to indirect mode. Even `git commit -a` reverts back to indirect mode, thanks to the pre-commit hook. I have tested that all these recovery methods work as intended. + +That leaves `git annex lock --force` (it has to be forced) after an interrupted switch to direct mode. I have reproduced that in this situation, that will delete your file's contents (I cannot reproduce them ending up in misctmp, but [[!commit d8be828734704c78f91029263b59eed75174e665]] may have had something to do with that). In a sense, `git annex lock --force` is doing what you told it to -- git-annex lock throws unlocked file contents away, under the assumption that they might contain modified changes. Since normally, `git annex unlock` makes a copy of the file, there is not normally data loss, unless the unlocked files got modified. But that's why it requires the --force; it can result in data loss. + +I a having a hard time thinking of a modification to `git annex lock` that would make sense. The best I can come up with is, if the file's content is not present in the annex, it could switch to what `git annex add` does, and re-add the file content to the annex if it's unchanged. While, I guess, throwing away the content if it is changed. That seems a bit complicated. + +(BTW, if you do still have the files in misctmp, you can `git annex import` their content back into the repository.) +"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment new file mode 100644 index 000000000..b55e3c2a3 --- /dev/null +++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-15T17:39:14Z" + content=""" +I still cannot see a way that more than one file's content could end up in misctemp, since `git annex direct` moves just one file there at a time, so max of one should be there if interrupted. However, there was really no reason to be moving files through misctemp at all, so `git annex direct` now moves them into place completely atomically. + +Bug report retitled appropriatly for the `git annex lock --force` suprise. +"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn index 8727d3d93..d435f8c28 100644 --- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn +++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn @@ -42,3 +42,5 @@ foo git-annex version: 5.20140717 git version 2.0.1 Linux durian 3.14-1-amd64 #1 SMP Debian 3.14.9-1 (2014-06-30) x86_64 GNU/Linux + +[[!tag confirmed git-bug]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment new file mode 100644 index 000000000..c4d78fa03 --- /dev/null +++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T18:24:57Z" + content=""" +Congrats on being the guy with newlines in his filenames.. someone had to do it! + +Similarly, `git annex add` on the file will fail with the same error and leave it where it is and not added. + +The problem here is that while git-annex is careful to use git commands with -z, so it gets \"foo\nbar\" with a literal newline from git ls-files, `git cat-file --batch` speaks a line-based protocol. And, it parses filenames like `git ref-parse` does -- and AFAICS, that does not provide a way to input something like \"foo\\nbar\" with an escaped newline. Normally this doesn't matter, since the whole line of input is taken to be a filename, so there's no need to escape anything, but of course it fails with newlines. + +IMHO, the solution to this is to make `git cat-file --batch` have a -z option that enables NUL-delimited input (and probably output). If you want to see this happen, take it to the git developers.. + +(Should git annex import put files back if it fails to add them rather than leaving them sitting in the work tree?) +"""]] diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment new file mode 100644 index 000000000..cc9f7a9e8 --- /dev/null +++ b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-15T17:46:15Z" + content=""" +It seems that this has something to do with an auto `git gc` run being trigged somehow during the repair. Puzzlingly, I cannot find any code that would delete the .git/gc.pid file, unless it somehow shows up as a branch ref or something like that. + +Can you run the command with --debug so we can see which particular git command triggered the git gc? +"""]] diff --git a/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment new file mode 100644 index 000000000..1303a2077 --- /dev/null +++ b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T17:39:09Z" + content=""" +AFAICS, xmpp.l.google.com is the correct XMPP server; it's what the SRV record for googlemail.com says to use. + +Since it fails with an authentication error, I wonder if google's XMPP is rejecting a user@googlemail.com jid and expects the domain to be @gmail.com or something else. Would that be allowed by the XMPP spec? I don't know. + + +"""]] diff --git a/doc/bugs/protocol_mismatch_after_interrupt.mdwn b/doc/bugs/protocol_mismatch_after_interrupt.mdwn index 799ccc00f..c2c159057 100644 --- a/doc/bugs/protocol_mismatch_after_interrupt.mdwn +++ b/doc/bugs/protocol_mismatch_after_interrupt.mdwn @@ -30,4 +30,4 @@ workaround: `cd .git/annex/; mv transfer transfer.old` on the other side. -- [[anarcat]] -[[!taglink moreinfo]] +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/protocol_mismatch_after_interrupt/comment_2_e0894bd0d0037ee40050697748d4be47._comment b/doc/bugs/protocol_mismatch_after_interrupt/comment_2_e0894bd0d0037ee40050697748d4be47._comment new file mode 100644 index 000000000..5a1566b89 --- /dev/null +++ b/doc/bugs/protocol_mismatch_after_interrupt/comment_2_e0894bd0d0037ee40050697748d4be47._comment @@ -0,0 +1,47 @@ +[[!comment format=mdwn + username="https://id.koumbit.net/anarcat" + ip="72.0.72.144" + subject="more info" + date="2014-08-11T01:55:28Z" + content=""" +here's another occurence of that bug, with --debug this time: + +[[!format txt \"\"\" +anarcat@angela:video$ git annex --debug get films/Example/ +[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"films/Example/\"] +get films/Example/Example.mkv [2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"show-ref\",\"git-annex\"] +[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] +[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"log\",\"refs/heads/git-annex..7357c09b70e87f35fdc253316520975c94308299\",\"-n1\",\"--pretty=%H\"] +[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"log\",\"refs/heads/git-annex..30bd8b2d719734a73cbadba28dbc0c99107c201f\",\"-n1\",\"--pretty=%H\"] +[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"log\",\"refs/heads/git-annex..bde2aae11f2dcb3fb648ea5e5019fbab56301855\",\"-n1\",\"--pretty=%H\"] +[2014-08-10 21:49:23 EDT] chat: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"cat-file\",\"--batch\"] +[2014-08-10 21:49:23 EDT] read: git [\"config\",\"--null\",\"--list\"] +(from origin...) [2014-08-10 21:49:23 EDT] read: ssh [\"-O\",\"stop\",\"-S\",\"anarc.at\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"localhost\"] + +[2014-08-10 21:49:23 EDT] read: rsync [\"--progress\",\"--inplace\",\"--perms\",\"-e\",\"'ssh' '-S' '.git/annex/ssh/anarc.at' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'anarc.at' 'git-annex-shell ''sendkey'' ''/srv/video'' ''SHA256E-s815462420--a9a6eb45540fd7f3f2598453ef0fc948bec9abb764e85624d66c0707cbd93b22.mkv'' --uuid 5adbab10-0f7a-467b-b0d8-5d7af2223103 ''--'' ''remoteuuid=ae3d62e6-49be-4340-ba25-c8736a1637c4'' ''direct='' ''associatedfile=films/Example/Example.mkv'' ''--'''\",\"--\",\"dummy:\",\"/home/anarcat/video/.git/annex/tmp/SHA256E-s815462420--a9a6eb45540fd7f3f2598453ef0fc948bec9abb764e85624d66c0707cbd93b22.mkv\"] +protocol version mismatch -- is your shell clean? +(see the rsync man page for an explanation) +rsync error: protocol incompatibility (code 2) at compat.c(174) [Receiver=3.0.9] + + rsync failed -- run git annex again to resume file transfer + + Unable to access these remotes: origin + + Try making some of these repositories available: + 31912b57-62a5-475c-87a7-582b5492a216 -- WD green 1.5TB backup drive + 5adbab10-0f7a-467b-b0d8-5d7af2223103 -- main (anarcat@marcos:/srv/video) [origin] +failed +git-annex: get: 1 failed +\"\"\"]] + +running rsync directly doesn't give me much more info, however, running the `-e` command does: + +[[!format txt \"\"\" +anarcat@angela:video$ ssh '-S' '.git/annex/ssh/anarc.at' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'anarc.at' 'git-annex-shell ''sendkey'' ''/srv/video'' ''SHA256E-s815462420--a9a6eb45540fd7f3f2598453ef0fc948bec9abb764e85624d66c0707cbd93b22.mkv'' --uuid 5adbab10-0f7a-467b-b0d8-5d7af2223103 ''--'' ''remoteuuid=ae3d62e6-49be-4340-ba25-c8736a1637c4'' ''direct='' ''associatedfile=films/Example/Example.mkv'' ''--''' +(transfer already in progress) +\"\"\"]] + +so it seems that the remote thinks the transfer is still in progress. + +to reproduce this, switch between a wired and wireless connexion before interrupting the process. +"""]] diff --git a/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment b/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment new file mode 100644 index 000000000..742109cd6 --- /dev/null +++ b/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 3" + date="2014-08-15T18:02:12Z" + content=""" +Right .. Normally it makes sense to prevent redundant transfers, but this is not the case when git-annex-shell sendkey is sending a file to a remote. Especially since the rsync protocol does not transport stderr output over the link to display to the user. + +Should be an easy fix. +"""]] diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn index bd172b56e..16fa60718 100644 --- a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn +++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn @@ -18,3 +18,5 @@ Now when I try to copy a file to the xxx-s3 remote, I get the following error: git-annex: copy: 1 failed Any ideas what might be wrong? Is shared cipher broken somehow? + +> [[fixed|done]] --[[Joey]] diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment index 1268d8cd0..1268d8cd0 100644 --- a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment +++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment diff --git a/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment new file mode 100644 index 000000000..57d5ee0cf --- /dev/null +++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T19:37:56Z" + content=""" +This is not gpg trying to decrypt some file from the S3 remote. It is trying to decrypt the creds that embedcreds=yes caused to be stored in the git repo. + +I was able to reproduce this using your command line, with the S3 env vars set while running initremote, and then unset for the copy, which causes git-annex to try to get the creds from the git repo, and decrypt them. + +However, since encryption=shared, the encryption key is stored in the git repo, so there is no point at all in encrypting the creds, also stored in the git repo with that key. So `initremote` doesn't. The creds are simply stored base-64 encoded. + +I have fixed this. I will now move this thread to bugs so I can close it. +"""]] diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn index 1dbbbbba7..69302b0b1 100644 --- a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn +++ b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn @@ -1,8 +1,10 @@ ### Please describe the problem. -`git annex whereis` says that there are no copies of any of the files annexed in repositories running in direct mode. +`git annex whereis` says that there are no copies of any of the files that have been added in repositories running in direct mode. -This is the error received: +In other words, if I add a file from PC1 in direct mode, `whereis` in PC2 will fail. Instead, if I add the same file from PC1 in indirect mode, `whereis` in PC2 will work correctly and will report that the file is present in PC1. + +This is the error received in PC2: $ git annex whereis whereis fileA (0 copies) failed @@ -81,4 +83,4 @@ echo "Why isn't location info available even after sync? (press Enter)" ### What version of git-annex are you using? On what operating system? -git-annex version: 5.20140708-g42df533 +git-annex version: 5.20140716-g8c14ba8 diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment new file mode 100644 index 000000000..5775addc0 --- /dev/null +++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T17:29:16Z" + content=""" +I don't seem to reproduce this bug when I run the script provided. + +<pre> +whereis fileA (1 copy) + c311d5b9-2f59-4153-a0e5-61707edd28ef -- pc1 +ok +whereis fileB (1 copy) + c311d5b9-2f59-4153-a0e5-61707edd28ef -- pc1 +ok +</pre> +"""]] diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment new file mode 100644 index 000000000..d139aed36 --- /dev/null +++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T17:33:25Z" + content=""" +It seems to me that there are only 3 ways that pc2 could not know that pc1 has the file, in decreasing order of probability: + +1. pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled) +2. pc2 has not fetched git-annex branch from origin +3. an actual bug, such as bad info being written to the git-annex branch or the git-annex branch merge failing + +So, if you have 3 repositories that exhibit a problem like this, those are the things to check. +"""]] diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment new file mode 100644 index 000000000..6fb3b8046 --- /dev/null +++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://svario.it/gioele" + nickname="gioele" + subject="comment 3" + date="2014-08-13T06:36:52Z" + content=""" +This is strange: I can replicate the problem on three different Ubuntu machines (12.04.5 32 and 64 bit, 14.04 64 bit) using that script. + +I attached to the gist [the execution log in direct mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-direct-log) (where the bug is shown), the [log in indirect mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-indirect-log) (where the bug does not appear), and a [diff between the two](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-log-diff). I hope this helps. +"""]] diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment new file mode 100644 index 000000000..ffbbcc12a --- /dev/null +++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="http://svario.it/gioele" + nickname="gioele" + subject="comment 4" + date="2014-08-13T06:40:12Z" + content=""" +Talking about the three possible causes for this bug, + +> 1) pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled) + +pc1 pushes using `git annex sync -c annex.alwayscommit=true origin`. This should be enough, isn't it? + +> 2) pc2 has not fetched git-annex branch from origin + +The pc2 repository is created with `git clone localhost:/tmp/annex/Docs.git`, so there branches should all be there. I tried adding a `git fetch --all` to the script but it makes no difference. This is the list of branches in pc2: + + * master + remotes/origin/HEAD -> origin/master + remotes/origin/master + remotes/origin/synced/git-annex + remotes/origin/synced/master + +"""]] diff --git a/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn index 7112818ed..2b4a62538 100644 --- a/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn +++ b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn @@ -23,3 +23,5 @@ Not much in the logs, I see this: [2014-07-25 08:40:14 BST] TransferWatcher: transfer starting: Download UUID "00000000-0000-0000-0000-000000000001" Chase_Adam_at_Startup_School_NY_2014.mp4 Nothing """]] + +> [[fixed|done]] --[[Joey]] diff --git a/doc/devblog/day_214-215__wrapping_up_recent_work.mdwn b/doc/devblog/day_214-215__wrapping_up_recent_work.mdwn new file mode 100644 index 000000000..7e06e231b --- /dev/null +++ b/doc/devblog/day_214-215__wrapping_up_recent_work.mdwn @@ -0,0 +1,16 @@ +Yesterday, finished converting S3 to use the aws library. Very happy with +the result (no memory leaks! connection caching!), but s3-aws is not merged +into master yet. Waiting on a new release of the aws library so as to not +break Internet Archive S3 support. + +Today, spent a few hours adding more tests to `testremote`. The new tests +take a remote, and construct a modified version that is intentionally +unavailable. Then they make sure trying to use it fails in appropriate +ways. This was a very good thing to test; two bugs were immediately found +and fixed. + +And that wraps up several weeks of hacking on the core of git-annex's +remotes support, which started with reworking chunking and kind of took +on a life of its own. I plan a release of this new stuff in a week. The +next week will be spent catching up on 117 messages of backlog that +accumulated while I was in deep coding mode. diff --git a/doc/devblog/day_216__various_minor_bugs.mdwn b/doc/devblog/day_216__various_minor_bugs.mdwn new file mode 100644 index 000000000..a9c49a9dd --- /dev/null +++ b/doc/devblog/day_216__various_minor_bugs.mdwn @@ -0,0 +1,16 @@ +Working on getting caught up with backlog. 73 messages remain. + +Several minor bugs were fixed today. All edge cases. The most edge case one +of all, I could not fix: git-annex cannot add a file that has a newline +in its filename, because `git cat-file --batch`'s interface does not support such +filenames. + +Added a page [[documenting how verify the signatures of git-annex releases|install/verifying_downloads]]. + +Over the past couple days, all the autobuilders have been updated to new +dependencies needed by the recent work. Except for Windows, which needs to +be updated to the new Haskell Platform first, so hopefully soon. + +Turns out that upgrading unix-compat means that inode(like) numbers are +available even on Windows, which will make git-annex more robust there. +Win win. ;) diff --git a/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment b/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment new file mode 100644 index 000000000..a1cc9c3b7 --- /dev/null +++ b/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="EskildHustvedt" + ip="80.202.103.55" + subject="comment 1" + date="2014-08-14T05:30:46Z" + content=""" +What exactly does «git-annex cannot add a file that has a space in its filename» mean? git-annex (/assistant) actually can't handle tracking any file that has a space in its filename? +"""]] diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment new file mode 100644 index 000000000..e90238063 --- /dev/null +++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://launchpad.net/~rorymcc" + nickname="rorymcc" + subject="comment 2" + date="2014-08-11T18:37:46Z" + content=""" +Thanks for your reply. I think I might have done a \"git merge git-annex\" at some point (or many times), because I thought that was what you were supposed to do... :( PEBKAC I'll try to fix up my repository. Thanks. +"""]] diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment new file mode 100644 index 000000000..214444c61 --- /dev/null +++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://launchpad.net/~rorymcc" + nickname="rorymcc" + subject="comment 3" + date="2014-08-11T18:41:05Z" + content=""" +Would just standard \"git rm ./000/\" etc. in master be OK? Instead of hunting down and reverting all the commits? +"""]] diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment new file mode 100644 index 000000000..74a3a2a75 --- /dev/null +++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 4" + date="2014-08-12T17:50:15Z" + content=""" +Sure, it's fine to delete the files. The same info will be committed to git either way. +"""]] diff --git a/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment new file mode 100644 index 000000000..8591e79aa --- /dev/null +++ b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 6" + date="2014-08-12T17:48:34Z" + content=""" +There are a couple of problems with using the haskell code as a library that would need to be addressed: + +* I can't guarantee much about providing every interface in a compatible way going forward. It might make sense to pick out some key interfaces and make those stable, but I don't know what the right choices would be. +* If all of git-annex is a library, `cabal build` will build everything a second time. This is annoying when trying to do a fast edit/build/test cycle, but I don't know a way to make cabal not do it. AFAIK cabal build flags cannot be used to disable building a library. +"""]] diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn new file mode 100644 index 000000000..20f6d696a --- /dev/null +++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn @@ -0,0 +1,14 @@ +Hey, + +I lost some symlinks to my data and I do not know how to recover them. I was in view mode with some tag folders already there. I added _new_ files from outside annex into some folder and 'git annex add' those files. + +What I expected: Git-Annex should add those files to the annex, move the symlinks to the root of the annex (because there is no other way to tell where to put them) and tag them with the specific tag. That is the way I would like to work, first tag, then organize in folder structure. + +Now that seems not to be a scenario which has been respected? Because I don't see my files... anywhere. Not in master branch nor in the view branch (I already did 'git annex vpop'). If that is not supported and never will be git-annex should not accept data from the outside world if it is currently in view mode. + +Now, how do I get my symlinks back? I guess the content is still there, but the links are missing and I don't find any reference or history log to revert that. 'git annex unused' does not show them either. + +I hope somebody can help me :) + +Cheers, +Stephan diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment new file mode 100644 index 000000000..2ecde6390 --- /dev/null +++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="sts" + ip="134.147.240.107" + subject="comment 1" + date="2014-08-11T11:39:44Z" + content=""" +OK, I could find the commit where I have added the data. I can 'git show' the commit and see the keys. I can also checkout the commit and I can see my data. Now I tried to create symlinks based on the keys I found in the commit, so whats the right way? + + git annex examinekey SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv + SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv + + git annex fromkey SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv e01.mkv + git-annex: key (SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv) is not present in backend + +I am not sure what to do now :-/. +"""]] diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment new file mode 100644 index 000000000..e9122c069 --- /dev/null +++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T17:57:26Z" + content=""" +views are a somewhat new feature that still needs work, and you will find this question of what to do about a file added while in a view in the todo list [[here|design/metadata]]. + +Since views are just git branches, you can check out the view branch where you added the file, and it'll still be there. You could merge the branch (probably not a good idea since the filenames are moved around in the view). + +Using `fromkey` will also work, if you have the right key and the content is present in the annex -- I just tested it. +"""]] diff --git a/doc/forum/armhf_binary.mdwn b/doc/forum/armhf_binary.mdwn new file mode 100644 index 000000000..442fb121d --- /dev/null +++ b/doc/forum/armhf_binary.mdwn @@ -0,0 +1,3 @@ +Does a armhf binary tarball exist anywhere? I'm running Ubuntu trusty on a armhf platform (beagleboard), and the repository package is out of date. I might try to get the standalone armel binary working using multiarch, but that seems only slightly less painful than compiling from scratch. + +Or am I better off changing to a debian boot image, and be done with it? diff --git a/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment b/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment new file mode 100644 index 000000000..9a1e3a4af --- /dev/null +++ b/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-15T15:58:02Z" + content=""" +The standalone armel build should work fine on armhf, assuming that the kernel supports EABI, which I'm pretty sure it does (or multiarch armel would not work). +"""]] diff --git a/doc/forum/gcrypt_os_x_app_vs_brew.mdwn b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn new file mode 100644 index 000000000..98a2d5f5d --- /dev/null +++ b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn @@ -0,0 +1,18 @@ +Gcrypt remotes work when using the git-annex command bundled in the git-annex.app. But gcrypt doesn't work when git-annex is installed via home-brew (brew install git-annex). + +The initial push will work, any subsequent commands (push/pull) will fail with: + + gpg: anonymous recipient; trying secret key... + gpg: anonymous recipient; trying secret key... + gpg: anonymous recipient; trying secret key... + gpg: anonymous recipient; trying secret key... + gpg: decryption failed: No secret key + gcrypt: Failed to decrypt manifest! + +In both cases (app/brew) it tries the same keys. The app version will use its own version of gpg, which will trigger password prompts. With the brew version gpgtools is used, so I won't get any prompts. (Keychain) + +I tried "echo i | gpg -e -R XX -R XX | gpg -d" with the same recipients as the repo. It works well. + +Has anybody hints or ideas what to try next? + +Best, Jean-Louis diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment new file mode 100644 index 000000000..bcf094073 --- /dev/null +++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="Ganwell" + ip="178.174.3.221" + subject="Problem solved" + date="2014-08-14T23:53:05Z" + content=""" +It turns out gpgtools will save to wrong passphrase to the keychain without complaining. Thats why standard gpg worked and gpgtools didn't: There was a typo in the passphrase in the keychain. +"""]] diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment new file mode 100644 index 000000000..fcdfba41d --- /dev/null +++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-15T16:04:08Z" + content=""" +Note that you can avoid the trying of multiple keys by doing `git config gcrypt.publish-participants true` -- this is done by default by the assistant when setting up new gcrypt remotes. It needs my branch of git-remote-gcrypt, which is included in the osx app, I don't know which one is being used in brew. +"""]] diff --git a/doc/forum/usability:_what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment new file mode 100644 index 000000000..86099c0d5 --- /dev/null +++ b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T19:49:35Z" + content=""" +If I wanted to share files with someone, I'd set them up with a direct mode repository and link it to my (probably indirect mode) repository. + +The question then becomes, how can this person decide which files to get if they don't want to or cannot get everything. I think that [[tips/File_manager_integration]] is a pretty good answer, although it does involve adding extensions to file managers. At least it involves adding something, rather than convincing a suprisingly large number of people that their ideas about symlinks are wrong. There are other possible answers, like building a file selection UI into the webapp.. +"""]] diff --git a/doc/forum/usability:_what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment new file mode 100644 index 000000000..32ecdf0df --- /dev/null +++ b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://id.koumbit.net/anarcat" + ip="70.83.139.100" + subject="comment 2" + date="2014-08-12T19:56:58Z" + content=""" +the problem with this is that you end up having two copies of the same files (the direct and indirect repositories). also, the switch to direct mode exploded (because i screwed up, granted).... + +i have been thinking more and more than the webapp needs to have some sort of file manager as well, but that seems like a huge undertaking... + +a better file manager integration could certainly allow to improve this experience. for me the requirements would be: + +* \"clone this repo to\" - make a copy of this git annex repo to the specified target +* \"annex-copy those files to\" - the above + a file-transfer-like dialog that would track the total file transfer (as opposed to \"begin/end\" of single files, see also [[todo/do_not_bug_me_about_intermediate_files/]]) +* probably some more stuff +"""]] diff --git a/doc/install.mdwn b/doc/install.mdwn index 493fdea58..7fe21c9ba 100644 --- a/doc/install.mdwn +++ b/doc/install.mdwn @@ -3,7 +3,7 @@ [[!table format=dsv header=yes data=""" detailed instructions | quick install [[OSX]] | [download git-annex.app](http://downloads.kitenet.net/git-annex/OSX/current/) - [[Homebrew]] | `brew install git-annex` + [[OSX/Homebrew]] | `brew install git-annex` [[Android]] | [download git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/) **beta** [[Linux|linux_standalone]] | [download prebuilt linux tarball](http://downloads.kitenet.net/git-annex/linux/current/) [[Debian]] | `apt-get install git-annex` @@ -16,14 +16,11 @@ detailed instructions | quick install [[ScientificLinux5]] | [[openSUSE]] | [[Docker]] | -[[Windows]] | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **alpha** +[[Windows]] | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **beta** """]] -The downloaded package's integrity can be verified by the public PGP key. On Linux, - - $ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc - $ gpg --import gpg-pubey.asc - $ gpg --verify git-annex-standalone-*.tar.gz.sig +All the downloads above use https for security. For added security, see +[[verifying_downloads]]. ## Using cabal diff --git a/doc/install/Linux_standalone.mdwn b/doc/install/Linux_standalone.mdwn index 4e654febc..f7aca5b9a 100644 --- a/doc/install/Linux_standalone.mdwn +++ b/doc/install/Linux_standalone.mdwn @@ -5,9 +5,9 @@ prebuilt tarball of the most recent release. This tarball should work on most Linux systems. It has basically no dependencies and is self-contained. -* i386: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz) -* amd64: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz) -* armel: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-armel.tar.gz) +* x86-32: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz) +* x86-64: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz) +* arm: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-armel.tar.gz) To use, just unpack the tarball, `cd git-annex.linux` and run `./runshell` -- this sets up an environment where you can use `git annex`, as well @@ -18,7 +18,7 @@ Alternatively, you can unpack the tarball, and add the directory to your PATH. This lets you use `git annex`, without overriding your system's own versions of git, etc. -The armel version can be installed on NAS devices and other embedded ARM +The arm version can be installed on NAS devices and other embedded ARM linux systems. * [[tips/Synology_NAS_and_git_annex]] @@ -29,6 +29,6 @@ linux systems. A daily build is also available, thanks to Mesar Hameed and the University of Bath CS department. -* i386: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/i386/git-annex-standalone-i386.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/i386/)) -* amd64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/amd64/)) -* armel: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/armel/)) +* x86-32: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/i386/git-annex-standalone-i386.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/i386/)) +* x86-64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/amd64/)) +* arm: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/armel/)) diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn index 5a1505c60..0eab6eb4c 100644 --- a/doc/install/OSX.mdwn +++ b/doc/install/OSX.mdwn @@ -31,25 +31,9 @@ git-annex is now [[available in Homebrew|Homebrew]]! ## using MacPorts -Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]]. -The version provided by Macports is too old to work with current versions of git-annex. -Then execute +git-annex is not available in MacPorts, but can be built from source using +MacPorts tools. See [[MacPorts]]. -<pre> -sudo port install git-core ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig -sudo cabal update -PATH=$HOME/bin:$PATH -cabal install c2hs git-annex --bindir=$HOME/bin -</pre> +## building it yourself -## PATH setup - -Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example: -<pre> -PATH=$HOME/bin:$PATH -</pre> - -See also: - -* [[forum/OSX__39__s_haskell-platform_statically_links_things]] -* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]] +See [[porting]]. diff --git a/doc/install/Homebrew.mdwn b/doc/install/OSX/Homebrew.mdwn index bd9a840b0..bd9a840b0 100644 --- a/doc/install/Homebrew.mdwn +++ b/doc/install/OSX/Homebrew.mdwn diff --git a/doc/install/OSX/MacPorts.mdwn b/doc/install/OSX/MacPorts.mdwn new file mode 100644 index 000000000..379e42d12 --- /dev/null +++ b/doc/install/OSX/MacPorts.mdwn @@ -0,0 +1,27 @@ +This is not a recommended way to install git-annex. Use [[HomeBrew]] or the +prebuilt app bundle instead. + +But if you really want to use MacPorts: + +Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]]. +The version provided by Macports is too old to work with current versions of git-annex. +Then execute + +<pre> +sudo port install git-core ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig +sudo cabal update +PATH=$HOME/bin:$PATH +cabal install c2hs git-annex --bindir=$HOME/bin +</pre> + +## PATH setup + +Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example: +<pre> +PATH=$HOME/bin:$PATH +</pre> + +See also: + +* [[forum/OSX__39__s_haskell-platform_statically_links_things]] +* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]] diff --git a/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment index e7d42b534..e7d42b534 100644 --- a/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment +++ b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment diff --git a/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment index 69f3f0fee..69f3f0fee 100644 --- a/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment +++ b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment diff --git a/doc/install/OSX/comment_4_bbe99673033e4c48c8bb3db24ee419f9._comment b/doc/install/OSX/comment_4_bbe99673033e4c48c8bb3db24ee419f9._comment deleted file mode 100644 index f3838e890..000000000 --- a/doc/install/OSX/comment_4_bbe99673033e4c48c8bb3db24ee419f9._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" - nickname="Jimmy" - subject="comment 4" - date="2012-12-10T17:00:43Z" - content=""" -For those that care, I've updated my autobuilder to the latest version of haskell-platform 2012.4.0.0 and it appears to be building correctly. -"""]] diff --git a/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment new file mode 100644 index 000000000..902d87dd7 --- /dev/null +++ b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 8" + date="2014-08-15T19:26:07Z" + content=""" +@David, the bundle contains the man page since a while. + +@Michael, the best way to get a git-annex that does not use those bundled programs is probably to instead install it using homebrew. +"""]] diff --git a/doc/install/OSX/porting.mdwn b/doc/install/OSX/porting.mdwn new file mode 100644 index 000000000..2003af684 --- /dev/null +++ b/doc/install/OSX/porting.mdwn @@ -0,0 +1,6 @@ +If you cannot get a OSX build of git-annex suitable for your computer, +from eg [[HomeBrew]] or the regular [[OSX]] prebuilt app, you +can try building git-annex from source on OSX, using haskell's cabal package +manager. + +For general instructions for using cabal, see [[this page|/install/cabal]]. diff --git a/doc/install/OSX/comment_10_cd2120552ef894a37933b328136fa4cc._comment b/doc/install/OSX/porting/comment_10_cd2120552ef894a37933b328136fa4cc._comment index c2b43b2dd..c2b43b2dd 100644 --- a/doc/install/OSX/comment_10_cd2120552ef894a37933b328136fa4cc._comment +++ b/doc/install/OSX/porting/comment_10_cd2120552ef894a37933b328136fa4cc._comment diff --git a/doc/install/OSX/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment b/doc/install/OSX/porting/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment index d0c74d609..d0c74d609 100644 --- a/doc/install/OSX/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment +++ b/doc/install/OSX/porting/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment diff --git a/doc/install/OSX/comment_12_a84028080578a8b60115b6c4ef823627._comment b/doc/install/OSX/porting/comment_12_a84028080578a8b60115b6c4ef823627._comment index cc57cbdfb..cc57cbdfb 100644 --- a/doc/install/OSX/comment_12_a84028080578a8b60115b6c4ef823627._comment +++ b/doc/install/OSX/porting/comment_12_a84028080578a8b60115b6c4ef823627._comment diff --git a/doc/install/OSX/comment_13_d6f1db401858ffea23c123db49f5b296._comment b/doc/install/OSX/porting/comment_13_d6f1db401858ffea23c123db49f5b296._comment index 875db34f1..875db34f1 100644 --- a/doc/install/OSX/comment_13_d6f1db401858ffea23c123db49f5b296._comment +++ b/doc/install/OSX/porting/comment_13_d6f1db401858ffea23c123db49f5b296._comment diff --git a/doc/install/OSX/comment_14_035f856923276b0edad879e196e94097._comment b/doc/install/OSX/porting/comment_14_035f856923276b0edad879e196e94097._comment index 1072dbc39..1072dbc39 100644 --- a/doc/install/OSX/comment_14_035f856923276b0edad879e196e94097._comment +++ b/doc/install/OSX/porting/comment_14_035f856923276b0edad879e196e94097._comment diff --git a/doc/install/OSX/comment_15_336e0acb00e84943715e69917643a69e._comment b/doc/install/OSX/porting/comment_15_336e0acb00e84943715e69917643a69e._comment index 05f5654bc..05f5654bc 100644 --- a/doc/install/OSX/comment_15_336e0acb00e84943715e69917643a69e._comment +++ b/doc/install/OSX/porting/comment_15_336e0acb00e84943715e69917643a69e._comment diff --git a/doc/install/OSX/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment b/doc/install/OSX/porting/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment index 0098e745d..0098e745d 100644 --- a/doc/install/OSX/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment +++ b/doc/install/OSX/porting/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment diff --git a/doc/install/OSX/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment b/doc/install/OSX/porting/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment index 8955ab20b..8955ab20b 100644 --- a/doc/install/OSX/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment +++ b/doc/install/OSX/porting/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment diff --git a/doc/install/OSX/comment_18_537fad5d8854e765499d47602d1ab398._comment b/doc/install/OSX/porting/comment_18_537fad5d8854e765499d47602d1ab398._comment index 9d8d8f755..9d8d8f755 100644 --- a/doc/install/OSX/comment_18_537fad5d8854e765499d47602d1ab398._comment +++ b/doc/install/OSX/porting/comment_18_537fad5d8854e765499d47602d1ab398._comment diff --git a/doc/install/OSX/comment_19_18d4377f4ded5604d395d73783ba82c9._comment b/doc/install/OSX/porting/comment_19_18d4377f4ded5604d395d73783ba82c9._comment index f244951e8..f244951e8 100644 --- a/doc/install/OSX/comment_19_18d4377f4ded5604d395d73783ba82c9._comment +++ b/doc/install/OSX/porting/comment_19_18d4377f4ded5604d395d73783ba82c9._comment diff --git a/doc/install/OSX/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment b/doc/install/OSX/porting/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment index 7dfa48132..7dfa48132 100644 --- a/doc/install/OSX/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment +++ b/doc/install/OSX/porting/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment diff --git a/doc/install/OSX/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment b/doc/install/OSX/porting/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment index 08792aa21..08792aa21 100644 --- a/doc/install/OSX/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment +++ b/doc/install/OSX/porting/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment diff --git a/doc/install/OSX/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment b/doc/install/OSX/porting/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment index 4b4bf3eb7..4b4bf3eb7 100644 --- a/doc/install/OSX/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment +++ b/doc/install/OSX/porting/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment diff --git a/doc/install/OSX/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment b/doc/install/OSX/porting/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment index 9a5b9c9c1..9a5b9c9c1 100644 --- a/doc/install/OSX/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment +++ b/doc/install/OSX/porting/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment diff --git a/doc/install/OSX/comment_27_d453510b9bb62072a4c663206c12c8a4._comment b/doc/install/OSX/porting/comment_27_d453510b9bb62072a4c663206c12c8a4._comment index cc9b44c1a..cc9b44c1a 100644 --- a/doc/install/OSX/comment_27_d453510b9bb62072a4c663206c12c8a4._comment +++ b/doc/install/OSX/porting/comment_27_d453510b9bb62072a4c663206c12c8a4._comment diff --git a/doc/install/OSX/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment b/doc/install/OSX/porting/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment index a672a70c4..a672a70c4 100644 --- a/doc/install/OSX/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment +++ b/doc/install/OSX/porting/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment diff --git a/doc/install/OSX/comment_29_8622ed56c6a8034c20fb311418d94003._comment b/doc/install/OSX/porting/comment_29_8622ed56c6a8034c20fb311418d94003._comment index c0552d9d9..c0552d9d9 100644 --- a/doc/install/OSX/comment_29_8622ed56c6a8034c20fb311418d94003._comment +++ b/doc/install/OSX/porting/comment_29_8622ed56c6a8034c20fb311418d94003._comment diff --git a/doc/install/OSX/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment b/doc/install/OSX/porting/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment index 9fcf7aa03..9fcf7aa03 100644 --- a/doc/install/OSX/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment +++ b/doc/install/OSX/porting/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment diff --git a/doc/install/OSX/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment b/doc/install/OSX/porting/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment index df9134194..df9134194 100644 --- a/doc/install/OSX/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment +++ b/doc/install/OSX/porting/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment diff --git a/doc/install/OSX/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment b/doc/install/OSX/porting/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment index 290da58f8..290da58f8 100644 --- a/doc/install/OSX/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment +++ b/doc/install/OSX/porting/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment diff --git a/doc/install/OSX/comment_33_203a36322b3c453c05c8906c64e62e06._comment b/doc/install/OSX/porting/comment_33_203a36322b3c453c05c8906c64e62e06._comment index 7e2853a4e..7e2853a4e 100644 --- a/doc/install/OSX/comment_33_203a36322b3c453c05c8906c64e62e06._comment +++ b/doc/install/OSX/porting/comment_33_203a36322b3c453c05c8906c64e62e06._comment diff --git a/doc/install/OSX/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment b/doc/install/OSX/porting/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment index 45b62b770..45b62b770 100644 --- a/doc/install/OSX/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment +++ b/doc/install/OSX/porting/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment diff --git a/doc/install/OSX/comment_8_38d9c2eea1090674de2361274eab5b0e._comment b/doc/install/OSX/porting/comment_8_38d9c2eea1090674de2361274eab5b0e._comment index bdc1698b7..bdc1698b7 100644 --- a/doc/install/OSX/comment_8_38d9c2eea1090674de2361274eab5b0e._comment +++ b/doc/install/OSX/porting/comment_8_38d9c2eea1090674de2361274eab5b0e._comment diff --git a/doc/install/OSX/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment b/doc/install/OSX/porting/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment index afb733443..afb733443 100644 --- a/doc/install/OSX/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment +++ b/doc/install/OSX/porting/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment diff --git a/doc/install/verifying_downloads.mdwn b/doc/install/verifying_downloads.mdwn new file mode 100644 index 000000000..c3413d431 --- /dev/null +++ b/doc/install/verifying_downloads.mdwn @@ -0,0 +1,31 @@ +When you download a git-annex package from downloads.kitenet.net, +as listed in [[install]], you should use a https connection. That provides +some security, but here's some more. + +The downloaded package's integrity can be verified by checking that +it was signed using the right GPG key, specifically the git-annex +distribution signing key. To do this, you need to download the .sig +file accompanying your package. Just append .sig to the url. + +For example, on Linux: + + $ wget http://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz + $ wget http://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz.sig + +You can then download the public key, and check that the package is signed +with it. + + $ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc + $ gpg --import gpg-pubey.asc + $ gpg --verify git-annex-standalone-*.tar.gz.sig + +(The git-annex assistant can automatically upgrade git-annex, and when it +does, it always checks the signature like that.) + +But, how do you know that the gpg-pubkey.asc you downloaded +is the right key? The answer is the GPG web of trust. + +* Joey Hess generates these git-annex packages, + and has a GPG key, [C910D9222512E3C Joey Hess <id@joeyh.name>](http://pgp.cs.uu.nl/stats/2512E3C7.html), which has + been verified and signed by many people. +* Joey's GPG key has signed the git-annex distribution signing key. diff --git a/doc/special_remotes/gcrypt.mdwn b/doc/special_remotes/gcrypt.mdwn index c9a22b01a..d5f3f7b5b 100644 --- a/doc/special_remotes/gcrypt.mdwn +++ b/doc/special_remotes/gcrypt.mdwn @@ -46,7 +46,7 @@ force it to re-push everything again, so that the encrypted repository can be decrypted by the added keys. Probably this can be done by setting `GCRYPT_FULL_REPACK` and doing a forced push of branches. -Recent versions of git-annex configure gcrypt-publish-participants when +Recent versions of git-annex configure `remote.<name>`gcrypt-publish-participants` when setting up a gcrypt repository. This is done to avoid unncessary gpg passphrase prompts, but it does publish the gpg keyids that can decrypt the repository. Unset it if you need to obscure that. diff --git a/doc/tips/dumb_metadata_extraction_from_xbmc.mdwn b/doc/tips/dumb_metadata_extraction_from_xbmc.mdwn new file mode 100644 index 000000000..652c37e5b --- /dev/null +++ b/doc/tips/dumb_metadata_extraction_from_xbmc.mdwn @@ -0,0 +1,29 @@ +I wanted to get the list of movies I haven't seen yet in XBMC, and i'm lazy. So I'll use [[metadata]] to be able to extract those movies only, for the road for example. + +First I fiddled around with shell scripts to extract the list of those films, which in XBMC-speak means that have a `NULL playCount`. Since there are two ways that XMBC can represent those files (in a `stack://` if there is multiple files for the movie or not), there are two scripts. For "stacked" movies: + + echo 'SELECT files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath WHERE playCount IS NULL AND files.strFileName LIKE "stack://%";' | sqlite3 /home/video/.xbmc/userdata/Database/MyVideos75.db | sed "s#stack://##;s/, /\n/g" | sed "s#/home/media/video/##" + +And the rest: + + echo 'SELECT path.strPath || files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath WHERE playCount IS NULL AND files.strFileName NOT LIKE "stack://%";' | sqlite3 /home/video/.xbmc/userdata/Database/MyVideos75.db | sed "s#/home/media/video/##" + +Also notice how I remove the absolute prefix for the annex so that i can refer to files as a relative path. + +So this quick and dirty hack could have been used to mark files as "new". Unfortunately, this won't unmark them when the playcount increases. So instead I think this should be a field, and we need to extract the playcount. Play around with shell scripting enough to get sick, get back into bad perl habits and you'll end up with this nasty script: [[git-annex-xbmc-playcount.pl]]. + +After the script is ran, you can sort the files by play count with: + + git annex view "playCount=*" + +Or just show the files that haven't been played yet: + + git annex view playCount=0 + +Use `git checkout master` to reset the view. Note that the above will flatten the tree hierarchy, which you may not way. Try this in that case: + + git annex view playCount=0 films/=* + +For more information, see [[tips/metadata_driven_views/]]. + +-- [[anarcat]] diff --git a/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl b/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl new file mode 100644 index 000000000..76ad33649 --- /dev/null +++ b/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl @@ -0,0 +1,28 @@ +#! /usr/bin/perl -w + +my $dbpath="/home/video/.xbmc/userdata/Database/MyVideos75.db"; +my $prefix="/home/media/video/"; + +my @lines = `echo 'SELECT playCount, path.strPath, files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath;' | sqlite3 $dbpath`; +for (@lines) { + my ($count, $dir, $file) = split /\|/; + chomp $file; + # empty or non-numeric count is zero + if ($count !~ /[0-9]/) { + $count = 0; + } + $dir =~ s/$prefix//; + if ($file =~ s#stack://##) { + for (split /,/, $file) { + s/$prefix//; + s/^ //; + s/ $//; + my @cmd = (qw(git annex metadata --set), "playCount=$count", $_); + system(@cmd); + } + } + else { + my @cmd = (qw(git annex metadata --set), "playCount=$count", "$dir$file"); + system(@cmd); + } +} diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn index 314c283bf..c551b08d7 100644 --- a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn +++ b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn @@ -5,3 +5,5 @@ In this scenario, an online service (Bandcamp), automatically creates the archiv Would it be possible for git-annex to be able to detect this scenario (in a manner similar to zipcmp) and redirect an add/import to the already existing copy? I've found this due to trying to decommission an old annex by `git annex import --clean-duplicates ~/annex_old/.git/annex/objects` and finding these files being left. + +[[done]] --[[Joey]] diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment new file mode 100644 index 000000000..19548edb3 --- /dev/null +++ b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T19:51:38Z" + content=""" +All you need to do is unzip your zip file, and then `git annex add` or `git annex import` its contents. It will then automatically deduplicate. + +Due to the way compression works, two zip (or gz) files with identical contents but different checksums are unlikely to share many bytes in common. So git-annex cannot help with de-duplicating unless you unzip them. +"""]] diff --git a/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment new file mode 100644 index 000000000..b2bcd87eb --- /dev/null +++ b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 3" + date="2014-08-12T18:58:49Z" + content=""" +I think that to support this, the annex.largefiles preferred content expression would need to be supplimented with checks not available in the normal preferred content language. + +In general, it's important that preferred content expressions be able to be evaluated without having the file content locally available, and it needs to be possible for a repository to evaluate the preferred content of a sibling repository and know if its sibling wants a file. These things would be defeated by any mime-based expressions. So such expressions should only be available in annex.largefiles and not in other preferred content expressions. + +Calling out to `file` or some other external program could work. Although speed can be important. If the assistant is seeing a file frequently change, it's not ideal for it to be repeatedly running `file` on it. There does not seem to be a pure haskell MIME type checking library available at present. +"""]] diff --git a/doc/walkthrough/renaming_files.mdwn b/doc/walkthrough/renaming_files.mdwn index 7ae5f633c..d18b7da64 100644 --- a/doc/walkthrough/renaming_files.mdwn +++ b/doc/walkthrough/renaming_files.mdwn @@ -12,8 +12,7 @@ the symlink will break when the file is moved into a subdirectory. But, git-annex will fix this up for you when you commit -- it has a pre-commit hook that watches for and corrects broken symlinks. -## Direct mode - -Note that these git commands only work when git-annex is using indirect mode. Repositories created by the [[assistant]] are in [[direct_mode]]. Running 'git mv' in direct mode will give you an error: - - fatal: This operation must be run in a work tree +(Note that if a repository is in direct mode, you can't run normal git +commands in it. Instead, just move the files using non-git commands, and +`git annex add` and `git annex sync`. This walkthrough does not make a +direct mode repository.) |