diff options
Diffstat (limited to 'doc/bugs')
15 files changed, 166 insertions, 0 deletions
diff --git a/doc/bugs/Windows:_Annex_can_not_get_files.mdwn b/doc/bugs/Windows:_Annex_can_not_get_files.mdwn index 8f636138d..f23624032 100644 --- a/doc/bugs/Windows:_Annex_can_not_get_files.mdwn +++ b/doc/bugs/Windows:_Annex_can_not_get_files.mdwn @@ -158,3 +158,5 @@ ok C:\annex1>cd \annex2 """]] + +> [[fixed|done]]; a simple path calculation bug. --[[Joey]] diff --git a/doc/bugs/Windows:_Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment b/doc/bugs/Windows:_Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment new file mode 100644 index 000000000..f5878a2ed --- /dev/null +++ b/doc/bugs/Windows:_Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2015-04-14T17:28:11Z" + content=""" +There is quite a lot of unrelated noise in this bug report. For example, +when you run "git annex init dir1", you're telling git-annex to refer to +that repository as "dir1". It should thus be unsuprising when it does in +whereis etc messages about that repository. + +This is a duplicate of +<http://git-annex.branchable.com/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/> +"""]] diff --git a/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn index 311675126..070191a63 100644 --- a/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn +++ b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn @@ -160,3 +160,5 @@ Latest sync command should inject annex-uuid to .config file, but it does not. F [remote "c"] url = C:\\Annex fetch = +refs/heads/*:refs/remotes/c/* + +> [[fixed|done]]; a simple path calculation bug. --[[Joey]] diff --git a/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment new file mode 100644 index 000000000..6641bb75d --- /dev/null +++ b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2015-04-14T17:32:29Z" + content=""" +This is partly a bug in uuid discovery; however even after I manually fill +in the remote's annex-uuid, it cannot get the file. +"""]] diff --git a/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn b/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn new file mode 100644 index 000000000..f00a63a7a --- /dev/null +++ b/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn @@ -0,0 +1,49 @@ +### Please describe the problem. + +Every time I try to `addurl` with `magnet:` I get this error message: + + could not download torrent file + +### What steps will reproduce the problem? + + git-annex addurl "magnet:?xt=urn:btih:b548b3b8efce813d71c9355832b4382680b8abf9" + +### What version of git-annex are you using? On what operating system? + +* git-annex 5.20150409 +* ubuntu 14.04 x64 + +### Please provide any additional information below. + +[[!format sh """ + +git-annex addurl magnet:?xt=urn:btih:b548b3b8efce813d71c9355832b4382680b8abf9 +(downloading torrent file...) + +04/13 17:16:15 [NOTICE] IPv4 DHT: listening on UDP port 6930 + +04/13 17:16:15 [NOTICE] IPv4 BitTorrent: listening on TCP port 6890 + +04/13 17:16:15 [NOTICE] IPv6 BitTorrent: listening on TCP port 6890 +[#3e3bb9 74KiB/74KiB(100%) CN:13 SD:1] +04/13 17:16:33 [NOTICE] Download complete: [METADATA]b548b3b8efce813d71c9355832b4382680b8abf9 + +04/13 17:16:33 [NOTICE] Saved metadata as ../.git/annex/misctmp/URL--magnet&c,63xt,61urn&cbtih&cb548b3b8efce813d71c9355832b4382680b8abf9/meta/b548b3b8efce813d71c9355832b4382680b8abf9.torrent. + +Download Results: +gid |stat|avg speed |path/URI +======+====+===========+======================================================= +3e3bb9|OK | 0B/s|[MEMORY][METADATA]b548b3b8efce813d71c9355832b4382680b8abf9 + +Status Legend: +(OK):download completed. +addurl magnet:?xt=urn:btih:b548b3b8efce813d71c9355832b4382680b8abf9 + could not download torrent file +failed +git-annex: addurl: 1 failed + +"""]] + +> Looking at the code, it was looking for a file prefixed by ".torrent", +> but of course that should be suffixed instead. So, [[fixed|done]] +> --[[Joey]] diff --git a/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment index 43e6a390b..43e6a390b 100644 --- a/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment +++ b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment diff --git a/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn index 9eecdf5f5..991d05493 100644 --- a/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn +++ b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn @@ -40,3 +40,5 @@ upgrade supported from repository versions: 0 1 2 4 # End of transcript or log. """]] + +[[!tag moreinfo]] diff --git a/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn b/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn index cb1163996..215db1178 100644 --- a/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn +++ b/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn @@ -43,3 +43,5 @@ $ # End of transcript or log. """]] + +[[!tag moreinfo]] diff --git a/doc/bugs/fsck_reports_unsolvable_problem.mdwn b/doc/bugs/fsck_reports_unsolvable_problem.mdwn new file mode 100644 index 000000000..d0164f8bc --- /dev/null +++ b/doc/bugs/fsck_reports_unsolvable_problem.mdwn @@ -0,0 +1,20 @@ +### Please describe the problem. + +On my bare git-annex repo, `git annex fsck -q` reports: + + ** No known copies exist of SHA256E-s1212237--d2edd369f6a9005e23f022c7d797b166c66b90defc561329dbafab9a0fc0c7fc.jpg + +`git log -SSA256E...` returns nothing. `git annex repair` and `git annex forget` do not fix the problem. + +This means that running `fsck` from cron or a script will now always fail. There should be a way to recover from this situation. + +### What steps will reproduce the problem? + +According to IRC this "can happen if you annexed a file and then deleted it without ever committing to git". + + +### What version of git-annex are you using? On what operating system? + +5.20140717 from Ubuntu utopic + +[[!tag confirmed]] diff --git a/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment b/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment new file mode 100644 index 000000000..e43ed96f5 --- /dev/null +++ b/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment @@ -0,0 +1,51 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-04-14T16:57:15Z" + content=""" +case 1 + +1. git annex add file +2. git annex drop --force file +3. git rm file +4. git commit -m nochange + +case 2 + +1. git annex add file +2. git commit -m added +3. git annex drop --force file +4. git rm file +5. git commit -m removed + +fsck --all, or fsck in a bare repo, will repport the same problem in either +case; the only difference being that in the latter case you can see that +the master branch's history (or some user branch) did once include the lost +file. In the former case, only the git-annex branch ever had a commit made +about the lost file. + +The only way to remove this message would be either remove the log file +from the git-annex branch, or teach fsck to ignore it. + +Due to union merge it's not as simple as deleting the log file. A `git +annex forget` type transition is needed to avoid merging the log file back in +from elsewhere. It's certianly doable using the transition infrastructure. + +Or, fsck could have its own blacklist of known problems to not warn about. +in some ways that's more complex; in others it's perhaps simpler since it +avoids the complexity needed to handle transitions. (forced pushing, branch +rewriting on merge, etc) + +Either way, I think the question is what UI to use to identify these keys. +Seems like the user would have to examine their repos's history and +understand whether they've hit case 1, or case 2, vs when a file they +really wanted to have available in the history has actually been lost. +Fsck could give some guidance, but not a whole lot. Note that if the user +goofs up, they coud end up in a situation that's rather more a mess than +this one! + +(I've seen maybe half a dozen people reporting this problem before. I think +most or all of them were using fsck in a bare repository. It might be that, +if fsck in a bare repository didn't behave as fsck --all, nobody would +care.) +"""]] diff --git a/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn b/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn index 93d890d81..f77f33a32 100644 --- a/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn +++ b/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn @@ -117,3 +117,5 @@ git-annex: unknown command anarc.at </pre> Turning off `sshcaching` seems to work around the issue. Note that this happens even if the git repo is moved to a non-NFS filesystem, so I have the feeling it's not directly related to [this bugfix](http://source.git-annex.branchable.com/?p=source.git;a=commit;h=bd110516c09d318b298804efc4ee888270f3d601). + +> [[done]] diff --git a/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn index 07ae44e89..db41d0701 100644 --- a/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn +++ b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn @@ -27,3 +27,5 @@ arch linux x86_64 ### Please provide any additional information below. The S3 remote is encrypted with the default "hybrid" method + +[[!tag moreinfo]] diff --git a/doc/bugs/--list-tests_runs_tests.mdwn b/doc/bugs/list-tests_runs_tests.mdwn index cea58db84..cea58db84 100644 --- a/doc/bugs/--list-tests_runs_tests.mdwn +++ b/doc/bugs/list-tests_runs_tests.mdwn diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn index 72f0794a5..9c8f1b5ba 100644 --- a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn +++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn @@ -10,3 +10,6 @@ git version 1.9.5.msysgit.1. git-annex version: 5.20150317-g237d5b0. Windows 7 P ### Please provide any additional information below. This seems to be fixed by editing the shortcuts and setting the "Start in" parameter to the git installation directory. For me this is "C:\Program Files (x86)\Git". + +> I've renamed it. The old git-annex.lnk will be +> deleted by the installer if it exists. [[done]] --[[Joey]] diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_4_7bec797548ff4ea270b96f9c0aada62c._comment b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_4_7bec797548ff4ea270b96f9c0aada62c._comment new file mode 100644 index 000000000..1b9a4dcf3 --- /dev/null +++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_4_7bec797548ff4ea270b96f9c0aada62c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://launchpad.net/~eliasson" + nickname="eliasson" + subject="comment 4" + date="2015-04-10T15:35:30Z" + content=""" +Perhaps both? Changing the VBscript for existing users, and renaming the link as a more long term solution for new installations. + +I would argue that testing with newer Windows versions than XP is somewhat important. If you need money for a Windows license you could always launch another crowdfunding campaign... +"""]] |