diff options
Diffstat (limited to 'doc/bugs')
25 files changed, 306 insertions, 4 deletions
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/bugs/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 new file mode 100644 index 000000000..16fa60718 --- /dev/null +++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn @@ -0,0 +1,22 @@ +I am trying to S3 as a file store for git annex. I have set up the remote via the following command: + + git annex initremote xxx-s3 type=S3 encryption=shared embedcreds=yes datacenter=EU bucket=xxx-git-annex fileprefix=test/ + +The remote gets set up correctly and creates the directory I want, and adds a annex-uuid file. + +Now when I try to copy a file to the xxx-s3 remote, I get the following error: + + $ git annex add ssl-success-and-failure-with-tl-logs.log + add ssl-success-and-failure-with-tl-logs.log ok + (Recording state in git...) + $ git annex copy ssl-success-and-failure-with-tl-logs.log --to xxx-s3 + copy ssl-success-and-failure-with-tl-logs.log (gpg) gpg: no valid OpenPGP data found. + gpg: decrypt_message failed: eof + + git-annex: user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","10","--decrypt"] exited 2) + failed + git-annex: copy: 1 failed + +Any ideas what might be wrong? Is shared cipher broken somehow? + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/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 new file mode 100644 index 000000000..1268d8cd0 --- /dev/null +++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmAINLSovhWM_4_KrbngOcxduIbBuKv8ZA" + nickname="Nuutti" + subject="comment 1" + date="2014-08-01T09:28:21Z" + content=""" +Sorry, this should probably be in bugs. +"""]] 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]] |