diff options
Diffstat (limited to 'doc')
4 files changed, 54 insertions, 0 deletions
diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_12_862598cbf80693972b752277da269601._comment b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_12_862598cbf80693972b752277da269601._comment new file mode 100644 index 000000000..cb478ea09 --- /dev/null +++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_12_862598cbf80693972b752277da269601._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 12""" + date="2015-08-04T20:03:51Z" + content=""" +Windows build didn't actually get updated until now. + +And only the autobuild is updated, not the last release build of course. +"""]] diff --git a/doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment b/doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment new file mode 100644 index 000000000..0999585ab --- /dev/null +++ b/doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-08-04T20:09:36Z" + content=""" +The assistant's automation for setting up a remote ssh server is what looks +to be failing. It seems that this NAS has a problem with ssh being used to +run a sh -c command. Probably the NAS's shell is not POSIX compliant +in some way. + +The best thing to do in this situation is to set up the git remote +on the NAS manually. Once it's set up, the assistant should be able to use +it. +"""]] diff --git a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains_:_or___59__.mdwn b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains_:_or___59__.mdwn index 52fcf6eb7..934416df6 100644 --- a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains_:_or___59__.mdwn +++ b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains_:_or___59__.mdwn @@ -39,3 +39,10 @@ git-annex: get: 1 failed # End of transcript or log. """]] + +> Actually, this bug is fixable. And I have! I made it detect the problem +> path, and then fall back to making a directory in /tmp, symlinking the +> git-annex.linux directory into it, and using that as its base directory. +> +> Of course, that's a suboptimal configuration, but better than having some +> configurations where it doesn't work. --[[Joey]] diff --git a/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment b/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment new file mode 100644 index 000000000..b45648035 --- /dev/null +++ b/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-08-04T20:14:00Z" + content=""" +This is actually something that got worse when fsck changed to using a +database, rather than its old sticky-bit based hack. Parallel fsck used to +work entirely perfectly, they could even be run on the same directories w/o +processing files redundantly. + +Now, it's safe to run multiple fsck processes in parallel. However, since +the database is only occasionally updated, if the two fscks are working on +the same directory, one won't know that the other has already fscked a +file, and they'll tend to do redundant work. + +It'll work fine if you give concurrent fscks different directories +or sets of files to work on. The git-annex key (ie, symlink target of a +file) is the primary-key. + +Also, I'd at some point like to make git-annex fsck -J work. With +concurrent fsck jobs running in the same process, it could easily divide +work up amoung them. The only tricky part is the output of the concurrent +jobs would be scrambled and interleaved.. +"""]] |