From 5f43ed9ee939716720d11c49e1360a7ecf07becc Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 8 Apr 2016 17:07:03 -0400 Subject: windows does not like filenames starting with a dot, rename --- ...s__44___including_original_one__44___gone..mdwn | 240 --------------------- ...ent_1_3a3891c9d7ee808f6a71780cb628f23d._comment | 12 -- ...ent_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment | 27 --- ...ent_3_fff1e778a6334258c173a96e6bf7ef6a._comment | 10 - ...ent_4_2a86da97a89e28f0a0f5e160d4932ae6._comment | 19 -- ...ent_5_41b8e8e58025cc8c8f12efb9a51acd29._comment | 50 ----- ...ent_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment | 10 - ...ent_7_06de36dcde4c52ab74c8134f3242ac02._comment | 9 - ...es__44___including_original_one__44___gone.mdwn | 240 +++++++++++++++++++++ ...ent_1_3a3891c9d7ee808f6a71780cb628f23d._comment | 12 ++ ...ent_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment | 27 +++ ...ent_3_fff1e778a6334258c173a96e6bf7ef6a._comment | 10 + ...ent_4_2a86da97a89e28f0a0f5e160d4932ae6._comment | 19 ++ ...ent_5_41b8e8e58025cc8c8f12efb9a51acd29._comment | 50 +++++ ...ent_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment | 10 + ...ent_7_06de36dcde4c52ab74c8134f3242ac02._comment | 9 + ...d_certificates_with_jabber_fail_miserably..mdwn | 26 --- ...ent_1_13d27ba41d9ef78c8db534b6bc26314e._comment | 12 -- ...ent_2_018eed99e71680be9e7c0844020419bb._comment | 8 - ...ent_3_1e7578dd1321f399b12197056495b0b6._comment | 8 - ...ent_4_a1948b7cd6ea990c8f1be5e483c835fa._comment | 14 -- ...ent_5_293b333134c97dc666a825cc7a8b2b62._comment | 12 -- ...ed_certificates_with_jabber_fail_miserably.mdwn | 26 +++ ...ent_1_13d27ba41d9ef78c8db534b6bc26314e._comment | 12 ++ ...ent_2_018eed99e71680be9e7c0844020419bb._comment | 8 + ...ent_3_1e7578dd1321f399b12197056495b0b6._comment | 8 + ...ent_4_a1948b7cd6ea990c8f1be5e483c835fa._comment | 14 ++ ...ent_5_293b333134c97dc666a825cc7a8b2b62._comment | 12 ++ doc/bugs/box.com_never_stops_syncing..mdwn | 74 ------- ...ent_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment | 10 - ...ent_2_42574181aa721319ba54eadf0a15ddff._comment | 11 - ...ent_3_2ad727849070cfd52d6c719478e9cce3._comment | 8 - ...ent_4_83ce23e45f5a5845d4f04519ee14ec65._comment | 9 - ...ent_5_ef1c9d87b04db5047ab72167d3269687._comment | 8 - ...ent_6_c9cb39eba941678035f9b2888da1085c._comment | 10 - ...ent_7_4b0632a4e37c96959a8e6434e9fd86fb._comment | 17 -- ...ent_8_d9d318b8c958de6031ae323da20af625._comment | 55 ----- ...ent_9_689ac6a4a305197cf5566f98dab47b4b._comment | 8 - doc/bugs/box.com_never_stops_syncing.mdwn | 74 +++++++ ...ent_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment | 10 + ...ent_2_42574181aa721319ba54eadf0a15ddff._comment | 11 + ...ent_3_2ad727849070cfd52d6c719478e9cce3._comment | 8 + ...ent_4_83ce23e45f5a5845d4f04519ee14ec65._comment | 9 + ...ent_5_ef1c9d87b04db5047ab72167d3269687._comment | 8 + ...ent_6_c9cb39eba941678035f9b2888da1085c._comment | 10 + ...ent_7_4b0632a4e37c96959a8e6434e9fd86fb._comment | 17 ++ ...ent_8_d9d318b8c958de6031ae323da20af625._comment | 55 +++++ ...ent_9_689ac6a4a305197cf5566f98dab47b4b._comment | 8 + doc/forum/MegaAnnex_not_working..mdwn | 32 --- ...ent_1_5aa3fd366d4c78ca79bb58005a49791c._comment | 8 - ...ent_2_f3eaf1ee06ebac951514d865f298f9d3._comment | 8 - doc/forum/MegaAnnex_not_working.mdwn | 32 +++ ...ent_1_5aa3fd366d4c78ca79bb58005a49791c._comment | 8 + ...ent_2_f3eaf1ee06ebac951514d865f298f9d3._comment | 8 + ...__Failed_to_check_if_upgrade_is_available..mdwn | 36 ---- ...ent_1_ac7c1f39e723cbcd49d6497649e7e44f._comment | 13 -- ...___Failed_to_check_if_upgrade_is_available.mdwn | 36 ++++ ...ent_1_ac7c1f39e723cbcd49d6497649e7e44f._comment | 13 ++ ..._44____while_also_cloning_and_syncing_too..mdwn | 11 - ...ent_1_30205c1ba18e5dca2314f593e1a0e236._comment | 8 - ...ent_2_f8df728de28218a6b060ae9f08adac79._comment | 8 - ...ent_3_ba438b3a371261ee841665f1ae57eba2._comment | 8 - ...ent_4_9f72e6c7c14a77330297526aef260762._comment | 11 - ...ent_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment | 10 - ...__44____while_also_cloning_and_syncing_too.mdwn | 11 + ...ent_1_30205c1ba18e5dca2314f593e1a0e236._comment | 8 + ...ent_2_f8df728de28218a6b060ae9f08adac79._comment | 8 + ...ent_3_ba438b3a371261ee841665f1ae57eba2._comment | 8 + ...ent_4_9f72e6c7c14a77330297526aef260762._comment | 11 + ...ent_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment | 10 + ...doesn__39__t_send_it_to_working_directory..mdwn | 11 - ...ent_1_0c0a5999a92bf5880f2113177dc67cc2._comment | 11 - ...ent_2_c18083d9054f66f0bd51d63452af07eb._comment | 8 - ..._doesn__39__t_send_it_to_working_directory.mdwn | 11 + ...ent_1_0c0a5999a92bf5880f2113177dc67cc2._comment | 11 + ...ent_2_c18083d9054f66f0bd51d63452af07eb._comment | 8 + ...___42__files__42___into_an_annex.__bummer..mdwn | 3 - ...ent_1_752db25abb647804a1cc12c5b247378a._comment | 10 - ...ent_2_db6f4959c35732f72e7a90bd9f4c665c._comment | 8 - ...d___42__files__42___into_an_annex.__bummer.mdwn | 3 + ...ent_1_752db25abb647804a1cc12c5b247378a._comment | 10 + ...ent_2_db6f4959c35732f72e7a90bd9f4c665c._comment | 8 + ...git-annex_receives_from_more_than_one_src..mdwn | 12 -- ...ent_1_c805561fa714ff3930742bb330b340c9._comment | 20 -- ..._git-annex_receives_from_more_than_one_src.mdwn | 12 ++ ...ent_1_c805561fa714ff3930742bb330b340c9._comment | 20 ++ ...t_total_storage_limit_for_special_remotes..mdwn | 1 - ...ent_1_8945025ad54e28f48474f8931746a775._comment | 9 - ...ent_2_86aa368db46dfedb065a18edfa7c9ad4._comment | 11 - ...et_total_storage_limit_for_special_remotes.mdwn | 1 + ...ent_1_8945025ad54e28f48474f8931746a775._comment | 9 + ...ent_2_86aa368db46dfedb065a18edfa7c9ad4._comment | 11 + .../Slow_transfer_for_a_lot_of_small_files..mdwn | 20 -- ...ent_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment | 12 -- ...ent_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment | 8 - .../Slow_transfer_for_a_lot_of_small_files.mdwn | 20 ++ ...ent_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment | 12 ++ ...ent_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment | 8 + ...__58_____39__get__39___queue_and_schedule..mdwn | 32 --- ...ent_1_d6ab311beee2ce5f73ae325a4ae463d4._comment | 11 - ...t__58_____39__get__39___queue_and_schedule.mdwn | 32 +++ ...ent_1_d6ab311beee2ce5f73ae325a4ae463d4._comment | 11 + 102 files changed, 1007 insertions(+), 1007 deletions(-) delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment delete mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_7_06de36dcde4c52ab74c8134f3242ac02._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment create mode 100644 doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment delete mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably..mdwn delete mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment delete mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_2_018eed99e71680be9e7c0844020419bb._comment delete mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_3_1e7578dd1321f399b12197056495b0b6._comment delete mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment delete mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_5_293b333134c97dc666a825cc7a8b2b62._comment create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing..mdwn delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_2_42574181aa721319ba54eadf0a15ddff._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_3_2ad727849070cfd52d6c719478e9cce3._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_5_ef1c9d87b04db5047ab72167d3269687._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_6_c9cb39eba941678035f9b2888da1085c._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_8_d9d318b8c958de6031ae323da20af625._comment delete mode 100644 doc/bugs/box.com_never_stops_syncing./comment_9_689ac6a4a305197cf5566f98dab47b4b._comment create mode 100644 doc/bugs/box.com_never_stops_syncing.mdwn create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment create mode 100644 doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment delete mode 100644 doc/forum/MegaAnnex_not_working..mdwn delete mode 100644 doc/forum/MegaAnnex_not_working./comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment delete mode 100644 doc/forum/MegaAnnex_not_working./comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment create mode 100644 doc/forum/MegaAnnex_not_working.mdwn create mode 100644 doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment create mode 100644 doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment delete mode 100644 doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available..mdwn delete mode 100644 doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment create mode 100644 doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn create mode 100644 doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment delete mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too..mdwn delete mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_1_30205c1ba18e5dca2314f593e1a0e236._comment delete mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_2_f8df728de28218a6b060ae9f08adac79._comment delete mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_3_ba438b3a371261ee841665f1ae57eba2._comment delete mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_4_9f72e6c7c14a77330297526aef260762._comment delete mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment delete mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory..mdwn delete mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment delete mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_2_c18083d9054f66f0bd51d63452af07eb._comment create mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn create mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment create mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment delete mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer..mdwn delete mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_1_752db25abb647804a1cc12c5b247378a._comment delete mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment create mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn create mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment create mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment delete mode 100644 doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src..mdwn delete mode 100644 doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src./comment_1_c805561fa714ff3930742bb330b340c9._comment create mode 100644 doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn create mode 100644 doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment delete mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes..mdwn delete mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment delete mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment create mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes.mdwn create mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment create mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment delete mode 100644 doc/todo/Slow_transfer_for_a_lot_of_small_files..mdwn delete mode 100644 doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment delete mode 100644 doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment create mode 100644 doc/todo/Slow_transfer_for_a_lot_of_small_files.mdwn create mode 100644 doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment create mode 100644 doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment delete mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule..mdwn delete mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule./comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment create mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn create mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn deleted file mode 100644 index 0d442437d..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn +++ /dev/null @@ -1,240 +0,0 @@ -### Please describe the problem. - -I had set up git-annex on a mac; I had created an initial repository at ~/annex; I had created a second repository on an external drive, at /Volumes/Biblio/annex; I had paired with three other machines on the same network, (two linux, one other mac) and set up a remote server as a backup-type repository. All seemed well. It had finally finished syncing everything to the remote server (my upload speeds are slow). - -I closed the firefox window showing the dashboard. I wanted to reopen it, so I ran the git-annex.app again, presuming on a running instance that that just opens the browser back at the webapp. Firefox window opened, but the only repository was the second one I'd made on the external drive. - -I restarted, as best as I could work out: git-annex assistant --stop, then because that left behind a process, killall git-annex. Then restarted the app. - -Firefox opened on the webapp. I had two repositories: The one on the external drive (now the "Here" repo) and the one on ~/annex but only as if it was paired from a different machine. - -ie: I see only "celestia.local (rachel@celestia.local~/annex)". This machine *is* celestia.local. - -That's it. Startup scan took a couple of minutes but didn't add anything. Then it decided to sync to celestia.local, which it took a little time over but didn't apparently do anything. - -If I drop files into ~/annex they are not synced anywhere. ~/annex still has a .git directory, populated with git files, it looks intact. It's just not being seen. - -Is it possible because the user is prompted to create their initial repo at ~/Desktop/annex it will by default only look there, then start looking in external drives for it? So the fact I didn't want it on my desktop, but put it directly in home, meant it got lost on restart? - -git-annex vicfg in ~/annex shows me this: - -[[!format sh """ -# git-annex configuration -# -# Changes saved to this file will be recorded in the git-annex branch. -# -# Lines in this file have the format: -# setting uuid = value - -# Repository trust configuration -# (Valid trust levels: trusted semitrusted untrusted dead) -# (for web) -#trust 00000000-0000-0000-0000-000000000001 = semitrusted -# (for rachel@octavia:~/annex) -#trust 161dec38-e8be-43b8-86c5-555d35ce3416 = semitrusted -# (for rachel@celestia.local:~/annex) -#trust 179fcddf-e247-4577-804b-267feed8abb1 = semitrusted -# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) -#trust 256d5762-150d-4d5d-9340-517de298c874 = semitrusted -# (for twilight.local_annex (rachel@twilight:~/annex)) -#trust aeef7490-ce27-4255-b800-1947706c4a06 = semitrusted -# (for rachel@octavia:~/annex) -#trust c469fbce-f3b4-4e27-a54f-0b747797a7d5 = semitrusted -# (for annex (Biblio's Copy)) -#trust c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = semitrusted -# (for luna.strangenoises.org_annex) -#trust f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = semitrusted -# (for octavia.local_annex (rachel@octavia:~/annex)) -#trust f748a5ed-d870-48fb-b3ec-811488eb2faa = semitrusted -# (for rachel@twilight:~/annex) -#trust fcaba03e-1ba5-11e3-90f1-57fe1467e006 = semitrusted - -# Repository groups -# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) -# (Separate group names with spaces) -# (for rachel@octavia:~/annex) -group 161dec38-e8be-43b8-86c5-555d35ce3416 = client -# (for rachel@celestia.local:~/annex) -group 179fcddf-e247-4577-804b-267feed8abb1 = client -# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) -group 256d5762-150d-4d5d-9340-517de298c874 = client -# (for twilight.local_annex (rachel@twilight:~/annex)) -group aeef7490-ce27-4255-b800-1947706c4a06 = client -# (for rachel@octavia:~/annex) -group c469fbce-f3b4-4e27-a54f-0b747797a7d5 = client -# (for annex (Biblio's Copy)) -group c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = client -# (for octavia.local_annex (rachel@octavia:~/annex)) -group f748a5ed-d870-48fb-b3ec-811488eb2faa = client -# (for rachel@twilight:~/annex) -group fcaba03e-1ba5-11e3-90f1-57fe1467e006 = client -# (for luna.strangenoises.org_annex) -group f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = transfer -# (for web) -#group 00000000-0000-0000-0000-000000000001 = - -# Repository preferred contents -# (for rachel@octavia:~/annex) -content 161dec38-e8be-43b8-86c5-555d35ce3416 = standard -# (for rachel@celestia.local:~/annex) -content 179fcddf-e247-4577-804b-267feed8abb1 = standard -# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) -content 256d5762-150d-4d5d-9340-517de298c874 = standard -# (for twilight.local_annex (rachel@twilight:~/annex)) -content aeef7490-ce27-4255-b800-1947706c4a06 = standard -# (for rachel@octavia:~/annex) -content c469fbce-f3b4-4e27-a54f-0b747797a7d5 = standard -# (for annex (Biblio's Copy)) -content c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = standard -# (for luna.strangenoises.org_annex) -content f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = standard -# (for octavia.local_annex (rachel@octavia:~/annex)) -content f748a5ed-d870-48fb-b3ec-811488eb2faa = standard -# (for rachel@twilight:~/annex) -content fcaba03e-1ba5-11e3-90f1-57fe1467e006 = standard -# (for web) -#content 00000000-0000-0000-0000-000000000001 = -"""]] - -while the same command in /Volumes/Biblio/annex gives: - -[[!format sh """ -# git-annex configuration -# -# Changes saved to this file will be recorded in the git-annex branch. -# -# Lines in this file have the format: -# setting uuid = value - -# Repository trust configuration -# (Valid trust levels: trusted semitrusted untrusted dead) -# (for web) -#trust 00000000-0000-0000-0000-000000000001 = semitrusted -# (for rachel@octavia:~/annex) -#trust 161dec38-e8be-43b8-86c5-555d35ce3416 = semitrusted -# (for celestia.local (rachel@celestia.local:~/annex)) -#trust 179fcddf-e247-4577-804b-267feed8abb1 = semitrusted -# (for rachel@rainbow.local:~/annex) -#trust 256d5762-150d-4d5d-9340-517de298c874 = semitrusted -# (for rachel@twilight:~/annex) -#trust aeef7490-ce27-4255-b800-1947706c4a06 = semitrusted -# (for rachel@octavia:~/annex) -#trust c469fbce-f3b4-4e27-a54f-0b747797a7d5 = semitrusted -# (for Biblio's Copy) -#trust c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = semitrusted -# (for ) -#trust f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = semitrusted -# (for rachel@octavia:~/annex) -#trust f748a5ed-d870-48fb-b3ec-811488eb2faa = semitrusted -# (for rachel@twilight:~/annex) -#trust fcaba03e-1ba5-11e3-90f1-57fe1467e006 = semitrusted - -# Repository groups -# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) -# (Separate group names with spaces) -# (for rachel@octavia:~/annex) -group 161dec38-e8be-43b8-86c5-555d35ce3416 = client -# (for celestia.local (rachel@celestia.local:~/annex)) -group 179fcddf-e247-4577-804b-267feed8abb1 = client -# (for rachel@rainbow.local:~/annex) -group 256d5762-150d-4d5d-9340-517de298c874 = client -# (for rachel@twilight:~/annex) -group aeef7490-ce27-4255-b800-1947706c4a06 = client -# (for rachel@octavia:~/annex) -group c469fbce-f3b4-4e27-a54f-0b747797a7d5 = client -# (for Biblio's Copy) -group c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = client -# (for rachel@octavia:~/annex) -group f748a5ed-d870-48fb-b3ec-811488eb2faa = client -# (for rachel@twilight:~/annex) -group fcaba03e-1ba5-11e3-90f1-57fe1467e006 = client -# (for ) -group f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = transfer -# (for web) -#group 00000000-0000-0000-0000-000000000001 = - -# Repository preferred contents -# (for rachel@octavia:~/annex) -content 161dec38-e8be-43b8-86c5-555d35ce3416 = standard -# (for celestia.local (rachel@celestia.local:~/annex)) -content 179fcddf-e247-4577-804b-267feed8abb1 = standard -# (for rachel@rainbow.local:~/annex) -content 256d5762-150d-4d5d-9340-517de298c874 = standard -# (for rachel@twilight:~/annex) -content aeef7490-ce27-4255-b800-1947706c4a06 = standard -# (for rachel@octavia:~/annex) -content c469fbce-f3b4-4e27-a54f-0b747797a7d5 = standard -# (for Biblio's Copy) -content c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = standard -# (for ) -content f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = standard -# (for rachel@octavia:~/annex) -content f748a5ed-d870-48fb-b3ec-811488eb2faa = standard -# (for rachel@twilight:~/annex) -content fcaba03e-1ba5-11e3-90f1-57fe1467e006 = standard -# (for web) -#content 00000000-0000-0000-0000-000000000001 = -"""]] - -### What steps will reproduce the problem? - -As above. I have no idea what just happened, but apart from git-annex assistant --stop and having to mop up leftover processes, I didn't use the git-annex commandline for anything. - -### What version of git-annex are you using? On what operating system? - -Mac OS X 10.8.4 - - Version: 4.20130909-ga29f960 - Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi - -### Please provide any additional information below. - -The log on ~/annex/.git/annex/daemon.log is huge and full of transfers of files with my personal filenames. I'd rather not. It appears to end normally. - -Now there is a short log in /Volumes/Biblio/annex/.git/annex/daemon.log from, I guess, the time I tried to restart. For some reason therefore, after the successful session finished, on restart it only looks here. This log is appended. - -[[!format sh """ -[2013-09-12 21:35:39 BST] main: starting assistant version 4.20130909-ga29f960 - -[2013-09-12 21:35:39 BST] TransferScanner: Syncing with celestia.local -Already up-to-date. - -(scanning...) [2013-09-12 21:35:39 BST] Watcher: Performing startup scan -From /Users/rachel/annex - * [new branch] git-annex -> celestia.local/git-annex - * [new branch] master -> celestia.local/master - * [new branch] synced/git-annex -> celestia.local/synced/git-annex - * [new branch] synced/master -> celestia.local/synced/master -Updating 4f974a8..74770d9 -Fast-forward -Already up-to-date. -Already up-to-date. -Already up-to-date. -[2013-09-12 21:36:39 BST] Pusher: Syncing with celestia.local -(merging celestia.local/git-annex celestia.local/synced/git-annex into git-annex...) -(Recording state in git...) - - - - -(started...) error: Ref refs/heads/synced/git-annex is at 5b4ed9b3098e936d60b61a1d3915fa29e8c823d0 but expected 792d2a5c14b0b6327d2089e174063c474ba5a764 -remote: error: failed to lock refs/heads/synced/git-annex -To /Users/rachel/annex - 792d2a5..5b4ed9b git-annex -> synced/git-annex -To /Users/rachel/annex - ! [remote rejected] git-annex -> synced/git-annex (failed to lock) -error: failed to push some refs to '/Users/rachel/annex' -Everything up-to-date -"""]] - -Well, I see that thing about "failed to lock". I can imagine that my 'killall git-annex' to kill a leftover process that was hanging around after I'd done git-annex assistant --stop might have left stale lock files, somewhere... but of course I only got as far as doing that because I was already encountering problems, just trying to return to the webapp. - -> The original bug report seems to be a case of user confusion, -> and not a bug. (Although perhaps the UI is confusing?) -> -> The "resource exhausted" that came up later is quite likely the problem -> fixed in [[!commit 4d06037fdd44ba38fcd4c118d1e6330f06e22366]], -> which affected local git remotes. -> -> [[closing|done]]; I don't see any value keeping this open, I'm afraid. -> --[[Joey]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment deleted file mode 100644 index 70e7ba79d..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 1" - date="2013-09-12T21:29:39Z" - content=""" -The git-annex webapp displays a view from \"inside\" one git repository at a time. It seems to me that you have two or more local git repositories; one in ~/annex and one on a removable drive. The webapp is coming up viewing from inside your removable drive's repository. You can change the repository that the webapp views by going to the Repository menu in the upper-right corner and selecting Switch repository. The webapp will remember which repository it viewed last, and come back up showing that same repository. - -It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\". - -I think, but am not sure, that the error \"Ref refs/heads/synced/git-annex is at 5b4ed9b3098e936d60b61a1d3915fa29e8c823d0 but expected 792d2a5c14b0b6327d2089e174063c474ba5a764\" is due to having two git-annex assistants running in these two different repositories and both updating them both at the same time. You might want to stop all git-annex processes, edit `~/.config/git-annex/autostart` and remove the removable drive repository from that list, leaving only `~/annex` in the list. -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment deleted file mode 100644 index 10fad2252..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="I don't know whether I've fixed it or confused things further" - date="2013-09-12T21:30:44Z" - content=""" -I shut down the daemon that was running from the webapp itself. - -Instead of launching by using the app, I did: - -[[!format txt \"\"\" -celestia:~ rachel$ cd annex/ -celestia:annex rachel$ git-annex assistant -(merging synced/git-annex into git-annex...) -celestia:annex rachel$ git-annex webapp -Launching web browser on file:///Users/rachel/annex/.git/annex/webapp.html -celestia:annex rachel$ -\"\"\"]] - -It opened the webapp. I could see all the repos back again. - -It also seems to be syncing to everything else, sending the files all over again, even though they haven't changed. - -It's just about possible it's completing the job, as I'm not sure I saw the files syncing now, being synced earlier. But... in that earlier session it had run the queue dry, *it* thought it had completed syncing. - -What's going on? -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment deleted file mode 100644 index 4d44aaf5c..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 3" - date="2013-09-12T21:33:18Z" - content=""" -See my explanation above. By manually starting the webapp inside your ~/annex repository you forced it to view that repository. - -It's not unusual for the webapp to display it syncing some files that have been synced before. This repository may not be up-to-date on which files have been sent where, and it will quickly notice the file has already been transferred and skip doing anything for that file. -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment deleted file mode 100644 index 16a5a351f..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="Last night's comment" - date="2013-09-13T10:28:02Z" - content=""" -> It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\". - -That is exactly how I'd added that repository, yes. I didn't notice the dedicated \"removable drive\" option until later. :-) I thought it possibly appropriate to leave it that way because, while Biblio is an external drive and remov*able*, in practice I never remove it; it's a permanent fixture. - -After all, this is a mac mini server, originally (no longer running Server) so it has a second *internal* drive. It would have been even more logical for me to have added a second repo on there in the same manner, as it's most definitely not removable without extreme effort; but it still mounts inside /Volumes, and presumably if I'd added it as a non-removable repo, I'd have had the same problem? - -> It's not unusual for the webapp to display it syncing some files that have been synced before. This repository may not be up-to-date on which files have been sent where, and it will quickly notice the file has already been transferred and skip doing anything for that file. - -Yes, that's probably what happened. It finished pretty quickly, about a minute after sending my previous comment. - -Going to bed now, but tomorrow I'll follow the remaining suggestions; basically I'll remove the repo on the external drive then, if I still want it there, I'll add it back in the other way, so it thinks of it as removable. - -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment deleted file mode 100644 index 685d1b024..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment +++ /dev/null @@ -1,50 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="And this morning..." - date="2013-09-13T10:38:35Z" - content=""" -I tried removing the second repo, by deleting it, it seemed to begin normally. Then it just hung, and hung. - -Looking at logs, it seemed to be hung on dropping one file - a very small file in fact, but it was probably the most recent file to be added. So the end of the log just looked like: - -[[!format txt \"\"\" -drop annex old stuff/renegade/issue7back.pdf ok -drop annex old stuff/renegade/issue7fiction.pdf ok -drop annex postgresql 9.0->9.1 upgrade process -\"\"\"]] - -After a while I started getting problems in other terminal shells where I was doing stuff unrelated to git annex. eg: on trying to open a new terminal window, it would open, then shut immediately, or it would open with just: - -[[!format txt \"\"\" -forkpty: Resource temporarily unavailable -Could not create a new process and open a pseudo-tty. -\"\"\"]] - -Various other commands that would have resulted in a fork were failing too. In the end I shut down git annex (using the shutdown daemon open in the menu in the webapp), and everything went back to normal. - -This is the end of the daemon.log from this morning. I don't want to paste the whole thing, as essentially it lists all my private filenames, and there's a lot. In fact I wonder if the quantity of files may be a factor: - -[[!format txt \"\"\" -drop annex old stuff/renegade/index.html ok -drop annex old stuff/renegade/issue1.pdf ok -drop annex old stuff/renegade/issue2.pdf ok -drop annex old stuff/renegade/issue3.pdf ok -drop annex old stuff/renegade/issue4.pdf ok -drop annex old stuff/renegade/issue4coverpic.pdf ok -drop annex old stuff/renegade/issue6articles.pdf ok -drop annex old stuff/renegade/issue6cover.pdf ok -drop annex old stuff/renegade/issue6fiction.pdf ok -drop annex old stuff/renegade/issue7articles.pdf ok -drop annex old stuff/renegade/issue7back.pdf ok -drop annex old stuff/renegade/issue7fiction.pdf ok -drop annex postgresql 9.0->9.1 upgrade process [2013-09-13 11:25:07 BST] NetWatcherFallback: Syncing with twilight.local_annex, octavia.local_annex, 192.168.1.103_annex, luna.strangenoises.org_annex -NetWatcherFallback crashed: git: createProcess: resource exhausted (Resource temporarily unavailable) -[2013-09-13 11:25:07 BST] NetWatcherFallback: warning NetWatcherFallback crashed: git: createProcess: resource exhausted (Resource temporarily unavailable) -recv: resource vanisrhreeecdcv v:(: C rorenesnsoeoucurtrciceoe n v varanenisiseshthe edbd y ( (CpCoeonennrne)ec -cttiioonn rreesseett bbyy ppeeeerr)) - -[2013-09-13 11:26:32 BST] main: warning git-annex has been shut down -\"\"\"]] - -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment deleted file mode 100644 index c0923b22a..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="comment 6" - date="2013-09-13T10:52:07Z" - content=""" -FYI, if there's any relevance to the number of files in the annex, there are 1899 files in the annex at the moment, so that many in the one being deleted. The one it hung on, \"postgresql 9.0->9.1 upgrade process\" was indeed the last one that comes up in a find command, which I think means the most recently added to this dir. - -Creating too many threads? -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_7_06de36dcde4c52ab74c8134f3242ac02._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_7_06de36dcde4c52ab74c8134f3242ac02._comment deleted file mode 100644 index c11630ef7..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_7_06de36dcde4c52ab74c8134f3242ac02._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="comment 7" - date="2013-09-13T10:54:37Z" - content=""" -... and resolved for myself by just deleting (dropping in the trash for now) the annex on the external volume, restarting git-annex assistant and *disabling* that repo from the menu rather than deleting it. - -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn new file mode 100644 index 000000000..0d442437d --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn @@ -0,0 +1,240 @@ +### Please describe the problem. + +I had set up git-annex on a mac; I had created an initial repository at ~/annex; I had created a second repository on an external drive, at /Volumes/Biblio/annex; I had paired with three other machines on the same network, (two linux, one other mac) and set up a remote server as a backup-type repository. All seemed well. It had finally finished syncing everything to the remote server (my upload speeds are slow). + +I closed the firefox window showing the dashboard. I wanted to reopen it, so I ran the git-annex.app again, presuming on a running instance that that just opens the browser back at the webapp. Firefox window opened, but the only repository was the second one I'd made on the external drive. + +I restarted, as best as I could work out: git-annex assistant --stop, then because that left behind a process, killall git-annex. Then restarted the app. + +Firefox opened on the webapp. I had two repositories: The one on the external drive (now the "Here" repo) and the one on ~/annex but only as if it was paired from a different machine. + +ie: I see only "celestia.local (rachel@celestia.local~/annex)". This machine *is* celestia.local. + +That's it. Startup scan took a couple of minutes but didn't add anything. Then it decided to sync to celestia.local, which it took a little time over but didn't apparently do anything. + +If I drop files into ~/annex they are not synced anywhere. ~/annex still has a .git directory, populated with git files, it looks intact. It's just not being seen. + +Is it possible because the user is prompted to create their initial repo at ~/Desktop/annex it will by default only look there, then start looking in external drives for it? So the fact I didn't want it on my desktop, but put it directly in home, meant it got lost on restart? + +git-annex vicfg in ~/annex shows me this: + +[[!format sh """ +# git-annex configuration +# +# Changes saved to this file will be recorded in the git-annex branch. +# +# Lines in this file have the format: +# setting uuid = value + +# Repository trust configuration +# (Valid trust levels: trusted semitrusted untrusted dead) +# (for web) +#trust 00000000-0000-0000-0000-000000000001 = semitrusted +# (for rachel@octavia:~/annex) +#trust 161dec38-e8be-43b8-86c5-555d35ce3416 = semitrusted +# (for rachel@celestia.local:~/annex) +#trust 179fcddf-e247-4577-804b-267feed8abb1 = semitrusted +# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) +#trust 256d5762-150d-4d5d-9340-517de298c874 = semitrusted +# (for twilight.local_annex (rachel@twilight:~/annex)) +#trust aeef7490-ce27-4255-b800-1947706c4a06 = semitrusted +# (for rachel@octavia:~/annex) +#trust c469fbce-f3b4-4e27-a54f-0b747797a7d5 = semitrusted +# (for annex (Biblio's Copy)) +#trust c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = semitrusted +# (for luna.strangenoises.org_annex) +#trust f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = semitrusted +# (for octavia.local_annex (rachel@octavia:~/annex)) +#trust f748a5ed-d870-48fb-b3ec-811488eb2faa = semitrusted +# (for rachel@twilight:~/annex) +#trust fcaba03e-1ba5-11e3-90f1-57fe1467e006 = semitrusted + +# Repository groups +# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) +# (Separate group names with spaces) +# (for rachel@octavia:~/annex) +group 161dec38-e8be-43b8-86c5-555d35ce3416 = client +# (for rachel@celestia.local:~/annex) +group 179fcddf-e247-4577-804b-267feed8abb1 = client +# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) +group 256d5762-150d-4d5d-9340-517de298c874 = client +# (for twilight.local_annex (rachel@twilight:~/annex)) +group aeef7490-ce27-4255-b800-1947706c4a06 = client +# (for rachel@octavia:~/annex) +group c469fbce-f3b4-4e27-a54f-0b747797a7d5 = client +# (for annex (Biblio's Copy)) +group c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = client +# (for octavia.local_annex (rachel@octavia:~/annex)) +group f748a5ed-d870-48fb-b3ec-811488eb2faa = client +# (for rachel@twilight:~/annex) +group fcaba03e-1ba5-11e3-90f1-57fe1467e006 = client +# (for luna.strangenoises.org_annex) +group f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = transfer +# (for web) +#group 00000000-0000-0000-0000-000000000001 = + +# Repository preferred contents +# (for rachel@octavia:~/annex) +content 161dec38-e8be-43b8-86c5-555d35ce3416 = standard +# (for rachel@celestia.local:~/annex) +content 179fcddf-e247-4577-804b-267feed8abb1 = standard +# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) +content 256d5762-150d-4d5d-9340-517de298c874 = standard +# (for twilight.local_annex (rachel@twilight:~/annex)) +content aeef7490-ce27-4255-b800-1947706c4a06 = standard +# (for rachel@octavia:~/annex) +content c469fbce-f3b4-4e27-a54f-0b747797a7d5 = standard +# (for annex (Biblio's Copy)) +content c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = standard +# (for luna.strangenoises.org_annex) +content f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = standard +# (for octavia.local_annex (rachel@octavia:~/annex)) +content f748a5ed-d870-48fb-b3ec-811488eb2faa = standard +# (for rachel@twilight:~/annex) +content fcaba03e-1ba5-11e3-90f1-57fe1467e006 = standard +# (for web) +#content 00000000-0000-0000-0000-000000000001 = +"""]] + +while the same command in /Volumes/Biblio/annex gives: + +[[!format sh """ +# git-annex configuration +# +# Changes saved to this file will be recorded in the git-annex branch. +# +# Lines in this file have the format: +# setting uuid = value + +# Repository trust configuration +# (Valid trust levels: trusted semitrusted untrusted dead) +# (for web) +#trust 00000000-0000-0000-0000-000000000001 = semitrusted +# (for rachel@octavia:~/annex) +#trust 161dec38-e8be-43b8-86c5-555d35ce3416 = semitrusted +# (for celestia.local (rachel@celestia.local:~/annex)) +#trust 179fcddf-e247-4577-804b-267feed8abb1 = semitrusted +# (for rachel@rainbow.local:~/annex) +#trust 256d5762-150d-4d5d-9340-517de298c874 = semitrusted +# (for rachel@twilight:~/annex) +#trust aeef7490-ce27-4255-b800-1947706c4a06 = semitrusted +# (for rachel@octavia:~/annex) +#trust c469fbce-f3b4-4e27-a54f-0b747797a7d5 = semitrusted +# (for Biblio's Copy) +#trust c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = semitrusted +# (for ) +#trust f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = semitrusted +# (for rachel@octavia:~/annex) +#trust f748a5ed-d870-48fb-b3ec-811488eb2faa = semitrusted +# (for rachel@twilight:~/annex) +#trust fcaba03e-1ba5-11e3-90f1-57fe1467e006 = semitrusted + +# Repository groups +# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) +# (Separate group names with spaces) +# (for rachel@octavia:~/annex) +group 161dec38-e8be-43b8-86c5-555d35ce3416 = client +# (for celestia.local (rachel@celestia.local:~/annex)) +group 179fcddf-e247-4577-804b-267feed8abb1 = client +# (for rachel@rainbow.local:~/annex) +group 256d5762-150d-4d5d-9340-517de298c874 = client +# (for rachel@twilight:~/annex) +group aeef7490-ce27-4255-b800-1947706c4a06 = client +# (for rachel@octavia:~/annex) +group c469fbce-f3b4-4e27-a54f-0b747797a7d5 = client +# (for Biblio's Copy) +group c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = client +# (for rachel@octavia:~/annex) +group f748a5ed-d870-48fb-b3ec-811488eb2faa = client +# (for rachel@twilight:~/annex) +group fcaba03e-1ba5-11e3-90f1-57fe1467e006 = client +# (for ) +group f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = transfer +# (for web) +#group 00000000-0000-0000-0000-000000000001 = + +# Repository preferred contents +# (for rachel@octavia:~/annex) +content 161dec38-e8be-43b8-86c5-555d35ce3416 = standard +# (for celestia.local (rachel@celestia.local:~/annex)) +content 179fcddf-e247-4577-804b-267feed8abb1 = standard +# (for rachel@rainbow.local:~/annex) +content 256d5762-150d-4d5d-9340-517de298c874 = standard +# (for rachel@twilight:~/annex) +content aeef7490-ce27-4255-b800-1947706c4a06 = standard +# (for rachel@octavia:~/annex) +content c469fbce-f3b4-4e27-a54f-0b747797a7d5 = standard +# (for Biblio's Copy) +content c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = standard +# (for ) +content f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = standard +# (for rachel@octavia:~/annex) +content f748a5ed-d870-48fb-b3ec-811488eb2faa = standard +# (for rachel@twilight:~/annex) +content fcaba03e-1ba5-11e3-90f1-57fe1467e006 = standard +# (for web) +#content 00000000-0000-0000-0000-000000000001 = +"""]] + +### What steps will reproduce the problem? + +As above. I have no idea what just happened, but apart from git-annex assistant --stop and having to mop up leftover processes, I didn't use the git-annex commandline for anything. + +### What version of git-annex are you using? On what operating system? + +Mac OS X 10.8.4 + + Version: 4.20130909-ga29f960 + Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi + +### Please provide any additional information below. + +The log on ~/annex/.git/annex/daemon.log is huge and full of transfers of files with my personal filenames. I'd rather not. It appears to end normally. + +Now there is a short log in /Volumes/Biblio/annex/.git/annex/daemon.log from, I guess, the time I tried to restart. For some reason therefore, after the successful session finished, on restart it only looks here. This log is appended. + +[[!format sh """ +[2013-09-12 21:35:39 BST] main: starting assistant version 4.20130909-ga29f960 + +[2013-09-12 21:35:39 BST] TransferScanner: Syncing with celestia.local +Already up-to-date. + +(scanning...) [2013-09-12 21:35:39 BST] Watcher: Performing startup scan +From /Users/rachel/annex + * [new branch] git-annex -> celestia.local/git-annex + * [new branch] master -> celestia.local/master + * [new branch] synced/git-annex -> celestia.local/synced/git-annex + * [new branch] synced/master -> celestia.local/synced/master +Updating 4f974a8..74770d9 +Fast-forward +Already up-to-date. +Already up-to-date. +Already up-to-date. +[2013-09-12 21:36:39 BST] Pusher: Syncing with celestia.local +(merging celestia.local/git-annex celestia.local/synced/git-annex into git-annex...) +(Recording state in git...) + + + + +(started...) error: Ref refs/heads/synced/git-annex is at 5b4ed9b3098e936d60b61a1d3915fa29e8c823d0 but expected 792d2a5c14b0b6327d2089e174063c474ba5a764 +remote: error: failed to lock refs/heads/synced/git-annex +To /Users/rachel/annex + 792d2a5..5b4ed9b git-annex -> synced/git-annex +To /Users/rachel/annex + ! [remote rejected] git-annex -> synced/git-annex (failed to lock) +error: failed to push some refs to '/Users/rachel/annex' +Everything up-to-date +"""]] + +Well, I see that thing about "failed to lock". I can imagine that my 'killall git-annex' to kill a leftover process that was hanging around after I'd done git-annex assistant --stop might have left stale lock files, somewhere... but of course I only got as far as doing that because I was already encountering problems, just trying to return to the webapp. + +> The original bug report seems to be a case of user confusion, +> and not a bug. (Although perhaps the UI is confusing?) +> +> The "resource exhausted" that came up later is quite likely the problem +> fixed in [[!commit 4d06037fdd44ba38fcd4c118d1e6330f06e22366]], +> which affected local git remotes. +> +> [[closing|done]]; I don't see any value keeping this open, I'm afraid. +> --[[Joey]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment new file mode 100644 index 000000000..70e7ba79d --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.51" + subject="comment 1" + date="2013-09-12T21:29:39Z" + content=""" +The git-annex webapp displays a view from \"inside\" one git repository at a time. It seems to me that you have two or more local git repositories; one in ~/annex and one on a removable drive. The webapp is coming up viewing from inside your removable drive's repository. You can change the repository that the webapp views by going to the Repository menu in the upper-right corner and selecting Switch repository. The webapp will remember which repository it viewed last, and come back up showing that same repository. + +It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\". + +I think, but am not sure, that the error \"Ref refs/heads/synced/git-annex is at 5b4ed9b3098e936d60b61a1d3915fa29e8c823d0 but expected 792d2a5c14b0b6327d2089e174063c474ba5a764\" is due to having two git-annex assistants running in these two different repositories and both updating them both at the same time. You might want to stop all git-annex processes, edit `~/.config/git-annex/autostart` and remove the removable drive repository from that list, leaving only `~/annex` in the list. +"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment new file mode 100644 index 000000000..10fad2252 --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment @@ -0,0 +1,27 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" + nickname="Rachel" + subject="I don't know whether I've fixed it or confused things further" + date="2013-09-12T21:30:44Z" + content=""" +I shut down the daemon that was running from the webapp itself. + +Instead of launching by using the app, I did: + +[[!format txt \"\"\" +celestia:~ rachel$ cd annex/ +celestia:annex rachel$ git-annex assistant +(merging synced/git-annex into git-annex...) +celestia:annex rachel$ git-annex webapp +Launching web browser on file:///Users/rachel/annex/.git/annex/webapp.html +celestia:annex rachel$ +\"\"\"]] + +It opened the webapp. I could see all the repos back again. + +It also seems to be syncing to everything else, sending the files all over again, even though they haven't changed. + +It's just about possible it's completing the job, as I'm not sure I saw the files syncing now, being synced earlier. But... in that earlier session it had run the queue dry, *it* thought it had completed syncing. + +What's going on? +"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment new file mode 100644 index 000000000..4d44aaf5c --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.51" + subject="comment 3" + date="2013-09-12T21:33:18Z" + content=""" +See my explanation above. By manually starting the webapp inside your ~/annex repository you forced it to view that repository. + +It's not unusual for the webapp to display it syncing some files that have been synced before. This repository may not be up-to-date on which files have been sent where, and it will quickly notice the file has already been transferred and skip doing anything for that file. +"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment new file mode 100644 index 000000000..16a5a351f --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" + nickname="Rachel" + subject="Last night's comment" + date="2013-09-13T10:28:02Z" + content=""" +> It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\". + +That is exactly how I'd added that repository, yes. I didn't notice the dedicated \"removable drive\" option until later. :-) I thought it possibly appropriate to leave it that way because, while Biblio is an external drive and remov*able*, in practice I never remove it; it's a permanent fixture. + +After all, this is a mac mini server, originally (no longer running Server) so it has a second *internal* drive. It would have been even more logical for me to have added a second repo on there in the same manner, as it's most definitely not removable without extreme effort; but it still mounts inside /Volumes, and presumably if I'd added it as a non-removable repo, I'd have had the same problem? + +> It's not unusual for the webapp to display it syncing some files that have been synced before. This repository may not be up-to-date on which files have been sent where, and it will quickly notice the file has already been transferred and skip doing anything for that file. + +Yes, that's probably what happened. It finished pretty quickly, about a minute after sending my previous comment. + +Going to bed now, but tomorrow I'll follow the remaining suggestions; basically I'll remove the repo on the external drive then, if I still want it there, I'll add it back in the other way, so it thinks of it as removable. + +"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment new file mode 100644 index 000000000..685d1b024 --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment @@ -0,0 +1,50 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" + nickname="Rachel" + subject="And this morning..." + date="2013-09-13T10:38:35Z" + content=""" +I tried removing the second repo, by deleting it, it seemed to begin normally. Then it just hung, and hung. + +Looking at logs, it seemed to be hung on dropping one file - a very small file in fact, but it was probably the most recent file to be added. So the end of the log just looked like: + +[[!format txt \"\"\" +drop annex old stuff/renegade/issue7back.pdf ok +drop annex old stuff/renegade/issue7fiction.pdf ok +drop annex postgresql 9.0->9.1 upgrade process +\"\"\"]] + +After a while I started getting problems in other terminal shells where I was doing stuff unrelated to git annex. eg: on trying to open a new terminal window, it would open, then shut immediately, or it would open with just: + +[[!format txt \"\"\" +forkpty: Resource temporarily unavailable +Could not create a new process and open a pseudo-tty. +\"\"\"]] + +Various other commands that would have resulted in a fork were failing too. In the end I shut down git annex (using the shutdown daemon open in the menu in the webapp), and everything went back to normal. + +This is the end of the daemon.log from this morning. I don't want to paste the whole thing, as essentially it lists all my private filenames, and there's a lot. In fact I wonder if the quantity of files may be a factor: + +[[!format txt \"\"\" +drop annex old stuff/renegade/index.html ok +drop annex old stuff/renegade/issue1.pdf ok +drop annex old stuff/renegade/issue2.pdf ok +drop annex old stuff/renegade/issue3.pdf ok +drop annex old stuff/renegade/issue4.pdf ok +drop annex old stuff/renegade/issue4coverpic.pdf ok +drop annex old stuff/renegade/issue6articles.pdf ok +drop annex old stuff/renegade/issue6cover.pdf ok +drop annex old stuff/renegade/issue6fiction.pdf ok +drop annex old stuff/renegade/issue7articles.pdf ok +drop annex old stuff/renegade/issue7back.pdf ok +drop annex old stuff/renegade/issue7fiction.pdf ok +drop annex postgresql 9.0->9.1 upgrade process [2013-09-13 11:25:07 BST] NetWatcherFallback: Syncing with twilight.local_annex, octavia.local_annex, 192.168.1.103_annex, luna.strangenoises.org_annex +NetWatcherFallback crashed: git: createProcess: resource exhausted (Resource temporarily unavailable) +[2013-09-13 11:25:07 BST] NetWatcherFallback: warning NetWatcherFallback crashed: git: createProcess: resource exhausted (Resource temporarily unavailable) +recv: resource vanisrhreeecdcv v:(: C rorenesnsoeoucurtrciceoe n v varanenisiseshthe edbd y ( (CpCoeonennrne)ec +cttiioonn rreesseett bbyy ppeeeerr)) + +[2013-09-13 11:26:32 BST] main: warning git-annex has been shut down +\"\"\"]] + +"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment new file mode 100644 index 000000000..c0923b22a --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" + nickname="Rachel" + subject="comment 6" + date="2013-09-13T10:52:07Z" + content=""" +FYI, if there's any relevance to the number of files in the annex, there are 1899 files in the annex at the moment, so that many in the one being deleted. The one it hung on, \"postgresql 9.0->9.1 upgrade process\" was indeed the last one that comes up in a find command, which I think means the most recently added to this dir. + +Creating too many threads? +"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment new file mode 100644 index 000000000..c11630ef7 --- /dev/null +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" + nickname="Rachel" + subject="comment 7" + date="2013-09-13T10:54:37Z" + content=""" +... and resolved for myself by just deleting (dropping in the trash for now) the annex on the external volume, restarting git-annex assistant and *disabling* that repo from the menu rather than deleting it. + +"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably..mdwn b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably..mdwn deleted file mode 100644 index a6c258332..000000000 --- a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably..mdwn +++ /dev/null @@ -1,26 +0,0 @@ -### Please describe the problem. -Entering a jabber address which's server got a selfsigned certificate, the process just fails, without asking for acceptance for that certificate. This is quite a showstopper. -(for example: jabber.ccc.de) - - -### What steps will reproduce the problem? -Try with an account from e.g. jabber.ccc.de - - -### What version of git-annex are you using? On what operating system? -Arch Linux, aur/git-annex-standalone 4.20130709-1 - -### Please provide any additional information below. -There is no logoutput to add... I'm sorry. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -[[!meta title="XMPP does not work with jabber.ccc.de"]] - -[[!tag moreinfo]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment deleted file mode 100644 index a591b51e1..000000000 --- a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.90" - subject="comment 1" - date="2013-07-16T17:33:23Z" - content=""" -Hmm, actually the XMPP library it's using does not fail on an invalid or self-signed cert. This is something that SSL using libraries sadly often get wrong, and yeah, I see I contacted the library author a while ago, and a \"sessionIsSecure\" has been added to it, which can be used to check if the cert was valid. - -This leaves open the question of what's happening with you on the CCC server. Did you get an error message? - - -"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_2_018eed99e71680be9e7c0844020419bb._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_2_018eed99e71680be9e7c0844020419bb._comment deleted file mode 100644 index 9caee8a73..000000000 --- a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_2_018eed99e71680be9e7c0844020419bb._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.90" - subject="comment 2" - date="2013-07-16T17:42:42Z" - content=""" -Actually, sessionIsSecure only tells me if it's using SSL at all; still waiting on the XMPP library to add cert checking.. -"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_3_1e7578dd1321f399b12197056495b0b6._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_3_1e7578dd1321f399b12197056495b0b6._comment deleted file mode 100644 index 62d723c7b..000000000 --- a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_3_1e7578dd1321f399b12197056495b0b6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~psycojoker" - nickname="psycojoker" - subject="comment 3" - date="2013-11-25T09:54:33Z" - content=""" -Just to confirm that I'm also affected. Maybe you should add the possibility in the error message next to \"is the password correct?\". -"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment deleted file mode 100644 index 6eec4ae9a..000000000 --- a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://xlogon.net/yminus" - nickname="http://xlogon.net/yminus" - subject="comment 4" - date="2014-05-08T21:12:49Z" - content=""" -When will this issue be fixed? Currently my Jabber account is on jabber.ccc.de. - -This is the error message: - - Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host jabberd.jabber.ccc.de.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"bad-protocol\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host jabberd.jabber.ccc.de.:80 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"bad-protocol\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]})) - -Can you advise me another trustworthy non-profit and free (free as in free beer\" as well as \"free as in free speech\") jabber server? -"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_5_293b333134c97dc666a825cc7a8b2b62._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_5_293b333134c97dc666a825cc7a8b2b62._comment deleted file mode 100644 index 37c86cc80..000000000 --- a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably./comment_5_293b333134c97dc666a825cc7a8b2b62._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.36" - subject="comment 5" - date="2014-05-24T20:03:46Z" - content=""" -AFAIKS, this is not a failure from a self-signed certificate. git-annex contacted the jabber server, accepted its certificate, and tried to log in. The jabber server rejected the login. - -This kind of problem has in the past turned out to involve incompatabilities in SASL authentication using some newish authentication schemes. Often it's been a bug in the XMPP server that's tickled by the haksell TLS library. See for example - -So, what XMPP server is used by CCC? -"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn new file mode 100644 index 000000000..a6c258332 --- /dev/null +++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn @@ -0,0 +1,26 @@ +### Please describe the problem. +Entering a jabber address which's server got a selfsigned certificate, the process just fails, without asking for acceptance for that certificate. This is quite a showstopper. +(for example: jabber.ccc.de) + + +### What steps will reproduce the problem? +Try with an account from e.g. jabber.ccc.de + + +### What version of git-annex are you using? On what operating system? +Arch Linux, aur/git-annex-standalone 4.20130709-1 + +### Please provide any additional information below. +There is no logoutput to add... I'm sorry. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +[[!meta title="XMPP does not work with jabber.ccc.de"]] + +[[!tag moreinfo]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment new file mode 100644 index 000000000..a591b51e1 --- /dev/null +++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.90" + subject="comment 1" + date="2013-07-16T17:33:23Z" + content=""" +Hmm, actually the XMPP library it's using does not fail on an invalid or self-signed cert. This is something that SSL using libraries sadly often get wrong, and yeah, I see I contacted the library author a while ago, and a \"sessionIsSecure\" has been added to it, which can be used to check if the cert was valid. + +This leaves open the question of what's happening with you on the CCC server. Did you get an error message? + + +"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment new file mode 100644 index 000000000..9caee8a73 --- /dev/null +++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.90" + subject="comment 2" + date="2013-07-16T17:42:42Z" + content=""" +Actually, sessionIsSecure only tells me if it's using SSL at all; still waiting on the XMPP library to add cert checking.. +"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment new file mode 100644 index 000000000..62d723c7b --- /dev/null +++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://launchpad.net/~psycojoker" + nickname="psycojoker" + subject="comment 3" + date="2013-11-25T09:54:33Z" + content=""" +Just to confirm that I'm also affected. Maybe you should add the possibility in the error message next to \"is the password correct?\". +"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment new file mode 100644 index 000000000..6eec4ae9a --- /dev/null +++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://xlogon.net/yminus" + nickname="http://xlogon.net/yminus" + subject="comment 4" + date="2014-05-08T21:12:49Z" + content=""" +When will this issue be fixed? Currently my Jabber account is on jabber.ccc.de. + +This is the error message: + + Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host jabberd.jabber.ccc.de.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"bad-protocol\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host jabberd.jabber.ccc.de.:80 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"bad-protocol\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]})) + +Can you advise me another trustworthy non-profit and free (free as in free beer\" as well as \"free as in free speech\") jabber server? +"""]] diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment new file mode 100644 index 000000000..37c86cc80 --- /dev/null +++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.36" + subject="comment 5" + date="2014-05-24T20:03:46Z" + content=""" +AFAIKS, this is not a failure from a self-signed certificate. git-annex contacted the jabber server, accepted its certificate, and tried to log in. The jabber server rejected the login. + +This kind of problem has in the past turned out to involve incompatabilities in SASL authentication using some newish authentication schemes. Often it's been a bug in the XMPP server that's tickled by the haksell TLS library. See for example + +So, what XMPP server is used by CCC? +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing..mdwn b/doc/bugs/box.com_never_stops_syncing..mdwn deleted file mode 100644 index d8e5391b5..000000000 --- a/doc/bugs/box.com_never_stops_syncing..mdwn +++ /dev/null @@ -1,74 +0,0 @@ -### Please describe the problem. -Git-annex will constantly sync most(if not all) my files to box.com - -### What steps will reproduce the problem? -1 - Use git-annex instead of Dropbox at work -2 - Boot computer. -3 - Watch it sync everything to box.com (even files i believe it has transferred each and every day for the last few months) - -### What version of git-annex are you using? On what operating system? -git-annex version: 4.20130827 - -But i have never seen it work satisfactory in any version. - -Also, i have seen this is 10+ different clean git-annexes. So it isn't annex specific. - -### Please provide any additional information below. - -I am going to add more debug to this bug constantly. (I intend to do a full 'git annex copy --to box.com --not --in box.com' daily, and see if the same files are transfered again and again) - - -For now, i see a few different issues already: - - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -tou@DSK1049:~/work-annex$ git annex copy --to box.com --not --in box.com 2>&1 | tee ../work-annex-copy-to-box.com-not-in-box.com-run1.log -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","show-ref","git-annex"] -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","show-ref","--hash","refs/heads/git-annex"] -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..dbe8b1cfa5f84126c45a39fdc7c7f26e272c71cc","--oneline","-n1"] -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..45e279375897a2cd7f5b893402e0ec25c1b23436","--oneline","-n1"] -[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..c4921be4434f751493fce1c932ac759214abacd4","--oneline","-n1"] -[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..d591398dc1cac824a5fc5bdacdcb82301a9b15a3","--oneline","-n1"] -[2013-09-11 09:24:54 CEST] chat: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","cat-file","--batch"] -[2013-09-11 09:24:54 CEST] read: git ["config","--null","--list"] -[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","ls-files","--cached","-z","--"] -[2013-09-11 09:24:54 CEST] chat: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","cat-file","--batch"] -copy Documents/Gamle catillo overførsler/Rapport b-bm.odt (gpg) (checking box.com...) ok -copy Documents/Gamle catillo overførsler/Rapport brandt skorstensfejeren.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/4a5/18e/GPGHMACSHA1--5f8660edac93899cf9adc5fadcc480ddc2992bb1/GPGHMACSHA1--5f8660edac93899cf9adc5fadcc480ddc2992bb1.chunkcount) failed -copy Documents/Gamle catillo overførsler/Rapport teamkoege.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/98d/ae7/GPGHMACSHA1--5253241407527aa6c980f1174fdbc32713c54c44/GPGHMACSHA1--5253241407527aa6c980f1174fdbc32713c54c44.chunkcount) failed -copy Documents/Gamle catillo overførsler/Rapport vikarborsen.odt (checking box.com...) ok -copy Documents/Gamle catillo overførsler/Rapport-terrariemesteren.odt (checking box.com...) ok -copy Documents/Gamle catillo overførsler/catillo-efhandel.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/9d9/aea/GPGHMACSHA1--1516eac1ec7b4ceaa840faebabde1f50f5db0a52/GPGHMACSHA1--1516eac1ec7b4ceaa840faebabde1f50f5db0a52.chunkcount) failed -copy Documents/Nøgeordsanalyse catillo104.xlsx (checking box.com...) (ResponseTimeout) failed -copy Documents/Søgeordsliste.txt (checking box.com...) ok -copy Documents/catillo guide.odt (checking box.com...) ok -copy Documents/guide bruger oprettelse.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/49e/175/GPGHMACSHA1--2b47737f8de7faac7704eaa322785edad63a921c/GPGHMACSHA1--2b47737f8de7faac7704eaa322785edad63a921c.chunkcount) failed -copy Documents/guide skift backup bånd.odt (checking box.com...) ok -copy Documents/lilletest.csv (checking box.com...) (failed to read https://www.box.com/dav/work-annex/915/373/GPGHMACSHA1--49ba3d5f63c012ae2cd2c0fc3e729178b1023c33/GPGHMACSHA1--49ba3d5f63c012ae2cd2c0fc3e729178b1023c33.chunkcount) failed -copy Dropbox/adams-scraper/CommonFunctions.py (checking box.com...) (ResponseTimeout) failed -copy Dropbox/adams-scraper/__pycache__/CommonFunctions.cpython-33.pyc (checking box.com...) (to box.com...) [2013-09-11 09:28:30 CEST] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","14","--symmetric","--force-mdc"] - -100% 0.0 B/s 0sResponseTimeout -ResponseTimeout -failed - - -# End of transcript or log. -"""]] - -More to come(full log) - -> This is [[fixed|done]] in git; when built with a new enough -> version of the haskell DAV library, git-annex disables the default 5 -> second timeout. -> -> It'll still be present in the Debian stable backports, which are -> built with an old version of DAV. Not much I can do about that; -> backporting DAV would be difficult. -> -> The daily builds are updated to use the new version. -> --[[Joey]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment b/doc/bugs/box.com_never_stops_syncing./comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment deleted file mode 100644 index ee1c88cc7..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 1" - date="2013-09-12T20:29:14Z" - content=""" -It seems you are getting a lot of timeouts from box.com, both when checking if content is present there and when uploading content that it does not have. - -I have heard some grumbles about box.com not being very reliable right now. -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_2_42574181aa721319ba54eadf0a15ddff._comment b/doc/bugs/box.com_never_stops_syncing./comment_2_42574181aa721319ba54eadf0a15ddff._comment deleted file mode 100644 index 5a0cde548..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_2_42574181aa721319ba54eadf0a15ddff._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="comment 2" - date="2013-09-12T20:54:33Z" - content=""" -The problem being. I've used box.com with one of my own hooks(owncloud), where it is completely stable! - -The instability is not a the box.com end. - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_3_2ad727849070cfd52d6c719478e9cce3._comment b/doc/bugs/box.com_never_stops_syncing./comment_3_2ad727849070cfd52d6c719478e9cce3._comment deleted file mode 100644 index 5eab58b3f..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_3_2ad727849070cfd52d6c719478e9cce3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 3" - date="2013-09-12T20:56:44Z" - content=""" -git-annex is using box.com's WebDAV interface. Is owncloud? -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment b/doc/bugs/box.com_never_stops_syncing./comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment deleted file mode 100644 index eb9dc5134..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="comment 4" - date="2013-09-12T21:33:29Z" - content=""" -It uses the following url https://www.box.com/dav - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_5_ef1c9d87b04db5047ab72167d3269687._comment b/doc/bugs/box.com_never_stops_syncing./comment_5_ef1c9d87b04db5047ab72167d3269687._comment deleted file mode 100644 index 9d9c1329b..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_5_ef1c9d87b04db5047ab72167d3269687._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 5" - date="2013-09-12T21:44:32Z" - content=""" -It may be that there is a timeout in the http library that I am using for webdav that is too low. See -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_6_c9cb39eba941678035f9b2888da1085c._comment b/doc/bugs/box.com_never_stops_syncing./comment_6_c9cb39eba941678035f9b2888da1085c._comment deleted file mode 100644 index 5eaf4f4bb..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_6_c9cb39eba941678035f9b2888da1085c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="comment 6" - date="2013-09-12T21:49:05Z" - content=""" -That would probably do it. With other implementations(fuse mount) i've seen stalls and other bad behaviour with that DAV server. - -The owncloud hook doesn't have a timeout set. It probably should have one to prevent a total stall. -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment b/doc/bugs/box.com_never_stops_syncing./comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment deleted file mode 100644 index 2ac3f360e..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="Logs" - date="2013-09-13T11:43:22Z" - content=""" -So have two days of logs now, and it doesn't look like it is retrying old files. - -http://paste.ubuntu.com/6101255/ <- day 1 - -http://paste.ubuntu.com/6101256/ <- day 2 - -Setting the computer to do the following loop over the weekend, lets see if everything is done come monday. - -for i in `seq 3 2000`; do git annex copy --to box.com --not --in box.com 2>&1 | tee ../work-annex-copy-to-box.com-not-in-box.com-run$i.log; done - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_8_d9d318b8c958de6031ae323da20af625._comment b/doc/bugs/box.com_never_stops_syncing./comment_8_d9d318b8c958de6031ae323da20af625._comment deleted file mode 100644 index 8dfbd6944..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_8_d9d318b8c958de6031ae323da20af625._comment +++ /dev/null @@ -1,55 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA" - nickname="Tobias" - subject="Update" - date="2013-09-18T11:17:33Z" - content=""" -Only just got back to work now. The script has done 10 iteration. This is the status: - - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run1.log |grep \" ok\"| wc -l -137 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run2.log |grep \" ok\"| wc -l -77 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run3.log |grep \" ok\"| wc -l -116 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run4.log |grep \" ok\"| wc -l -70 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run5.log |grep \" ok\"| wc -l -26 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run6.log |grep \" ok\"| wc -l -6 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run7.log |grep \" ok\"| wc -l -6 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run8.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run9.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run10.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run11.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run12.log |grep \" ok\"| wc -l -0 - -I have all the log files of course. - -tou@DSK1049:~/work-annex$ git annex find --not --in box.com| wc -l -1639 - -So, of the last 5 iteration 0 files of 1639 missing were transfered. Most of these files are <10kbyte - -http://paste.ubuntu.com/6123459/ <- pastebin of work-annex-copy-to-box.com-not-in-box.com-run11.log if it is of any use. - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing./comment_9_689ac6a4a305197cf5566f98dab47b4b._comment b/doc/bugs/box.com_never_stops_syncing./comment_9_689ac6a4a305197cf5566f98dab47b4b._comment deleted file mode 100644 index 99a0eb9ae..000000000 --- a/doc/bugs/box.com_never_stops_syncing./comment_9_689ac6a4a305197cf5566f98dab47b4b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.153.8.80" - subject="comment 9" - date="2013-09-28T19:34:42Z" - content=""" -Filed a bug on the DAV library about this: -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing.mdwn b/doc/bugs/box.com_never_stops_syncing.mdwn new file mode 100644 index 000000000..d8e5391b5 --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing.mdwn @@ -0,0 +1,74 @@ +### Please describe the problem. +Git-annex will constantly sync most(if not all) my files to box.com + +### What steps will reproduce the problem? +1 - Use git-annex instead of Dropbox at work +2 - Boot computer. +3 - Watch it sync everything to box.com (even files i believe it has transferred each and every day for the last few months) + +### What version of git-annex are you using? On what operating system? +git-annex version: 4.20130827 + +But i have never seen it work satisfactory in any version. + +Also, i have seen this is 10+ different clean git-annexes. So it isn't annex specific. + +### Please provide any additional information below. + +I am going to add more debug to this bug constantly. (I intend to do a full 'git annex copy --to box.com --not --in box.com' daily, and see if the same files are transfered again and again) + + +For now, i see a few different issues already: + + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +tou@DSK1049:~/work-annex$ git annex copy --to box.com --not --in box.com 2>&1 | tee ../work-annex-copy-to-box.com-not-in-box.com-run1.log +[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","show-ref","git-annex"] +[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","show-ref","--hash","refs/heads/git-annex"] +[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..dbe8b1cfa5f84126c45a39fdc7c7f26e272c71cc","--oneline","-n1"] +[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..45e279375897a2cd7f5b893402e0ec25c1b23436","--oneline","-n1"] +[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..c4921be4434f751493fce1c932ac759214abacd4","--oneline","-n1"] +[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..d591398dc1cac824a5fc5bdacdcb82301a9b15a3","--oneline","-n1"] +[2013-09-11 09:24:54 CEST] chat: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","cat-file","--batch"] +[2013-09-11 09:24:54 CEST] read: git ["config","--null","--list"] +[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","ls-files","--cached","-z","--"] +[2013-09-11 09:24:54 CEST] chat: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","cat-file","--batch"] +copy Documents/Gamle catillo overførsler/Rapport b-bm.odt (gpg) (checking box.com...) ok +copy Documents/Gamle catillo overførsler/Rapport brandt skorstensfejeren.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/4a5/18e/GPGHMACSHA1--5f8660edac93899cf9adc5fadcc480ddc2992bb1/GPGHMACSHA1--5f8660edac93899cf9adc5fadcc480ddc2992bb1.chunkcount) failed +copy Documents/Gamle catillo overførsler/Rapport teamkoege.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/98d/ae7/GPGHMACSHA1--5253241407527aa6c980f1174fdbc32713c54c44/GPGHMACSHA1--5253241407527aa6c980f1174fdbc32713c54c44.chunkcount) failed +copy Documents/Gamle catillo overførsler/Rapport vikarborsen.odt (checking box.com...) ok +copy Documents/Gamle catillo overførsler/Rapport-terrariemesteren.odt (checking box.com...) ok +copy Documents/Gamle catillo overførsler/catillo-efhandel.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/9d9/aea/GPGHMACSHA1--1516eac1ec7b4ceaa840faebabde1f50f5db0a52/GPGHMACSHA1--1516eac1ec7b4ceaa840faebabde1f50f5db0a52.chunkcount) failed +copy Documents/Nøgeordsanalyse catillo104.xlsx (checking box.com...) (ResponseTimeout) failed +copy Documents/Søgeordsliste.txt (checking box.com...) ok +copy Documents/catillo guide.odt (checking box.com...) ok +copy Documents/guide bruger oprettelse.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/49e/175/GPGHMACSHA1--2b47737f8de7faac7704eaa322785edad63a921c/GPGHMACSHA1--2b47737f8de7faac7704eaa322785edad63a921c.chunkcount) failed +copy Documents/guide skift backup bånd.odt (checking box.com...) ok +copy Documents/lilletest.csv (checking box.com...) (failed to read https://www.box.com/dav/work-annex/915/373/GPGHMACSHA1--49ba3d5f63c012ae2cd2c0fc3e729178b1023c33/GPGHMACSHA1--49ba3d5f63c012ae2cd2c0fc3e729178b1023c33.chunkcount) failed +copy Dropbox/adams-scraper/CommonFunctions.py (checking box.com...) (ResponseTimeout) failed +copy Dropbox/adams-scraper/__pycache__/CommonFunctions.cpython-33.pyc (checking box.com...) (to box.com...) [2013-09-11 09:28:30 CEST] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","14","--symmetric","--force-mdc"] + +100% 0.0 B/s 0sResponseTimeout +ResponseTimeout +failed + + +# End of transcript or log. +"""]] + +More to come(full log) + +> This is [[fixed|done]] in git; when built with a new enough +> version of the haskell DAV library, git-annex disables the default 5 +> second timeout. +> +> It'll still be present in the Debian stable backports, which are +> built with an old version of DAV. Not much I can do about that; +> backporting DAV would be difficult. +> +> The daily builds are updated to use the new version. +> --[[Joey]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment b/doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment new file mode 100644 index 000000000..ee1c88cc7 --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.51" + subject="comment 1" + date="2013-09-12T20:29:14Z" + content=""" +It seems you are getting a lot of timeouts from box.com, both when checking if content is present there and when uploading content that it does not have. + +I have heard some grumbles about box.com not being very reliable right now. +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment b/doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment new file mode 100644 index 000000000..5a0cde548 --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" + nickname="develop" + subject="comment 2" + date="2013-09-12T20:54:33Z" + content=""" +The problem being. I've used box.com with one of my own hooks(owncloud), where it is completely stable! + +The instability is not a the box.com end. + +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment b/doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment new file mode 100644 index 000000000..5eab58b3f --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.51" + subject="comment 3" + date="2013-09-12T20:56:44Z" + content=""" +git-annex is using box.com's WebDAV interface. Is owncloud? +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment b/doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment new file mode 100644 index 000000000..eb9dc5134 --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" + nickname="develop" + subject="comment 4" + date="2013-09-12T21:33:29Z" + content=""" +It uses the following url https://www.box.com/dav + +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment b/doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment new file mode 100644 index 000000000..9d9c1329b --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.4.51" + subject="comment 5" + date="2013-09-12T21:44:32Z" + content=""" +It may be that there is a timeout in the http library that I am using for webdav that is too low. See +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment b/doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment new file mode 100644 index 000000000..5eaf4f4bb --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" + nickname="develop" + subject="comment 6" + date="2013-09-12T21:49:05Z" + content=""" +That would probably do it. With other implementations(fuse mount) i've seen stalls and other bad behaviour with that DAV server. + +The owncloud hook doesn't have a timeout set. It probably should have one to prevent a total stall. +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment b/doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment new file mode 100644 index 000000000..2ac3f360e --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" + nickname="develop" + subject="Logs" + date="2013-09-13T11:43:22Z" + content=""" +So have two days of logs now, and it doesn't look like it is retrying old files. + +http://paste.ubuntu.com/6101255/ <- day 1 + +http://paste.ubuntu.com/6101256/ <- day 2 + +Setting the computer to do the following loop over the weekend, lets see if everything is done come monday. + +for i in `seq 3 2000`; do git annex copy --to box.com --not --in box.com 2>&1 | tee ../work-annex-copy-to-box.com-not-in-box.com-run$i.log; done + +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment b/doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment new file mode 100644 index 000000000..8dfbd6944 --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment @@ -0,0 +1,55 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA" + nickname="Tobias" + subject="Update" + date="2013-09-18T11:17:33Z" + content=""" +Only just got back to work now. The script has done 10 iteration. This is the status: + + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run1.log |grep \" ok\"| wc -l +137 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run2.log |grep \" ok\"| wc -l +77 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run3.log |grep \" ok\"| wc -l +116 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run4.log |grep \" ok\"| wc -l +70 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run5.log |grep \" ok\"| wc -l +26 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run6.log |grep \" ok\"| wc -l +6 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run7.log |grep \" ok\"| wc -l +6 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run8.log |grep \" ok\"| wc -l +0 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run9.log |grep \" ok\"| wc -l +0 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run10.log |grep \" ok\"| wc -l +0 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run11.log |grep \" ok\"| wc -l +0 + +tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run12.log |grep \" ok\"| wc -l +0 + +I have all the log files of course. + +tou@DSK1049:~/work-annex$ git annex find --not --in box.com| wc -l +1639 + +So, of the last 5 iteration 0 files of 1639 missing were transfered. Most of these files are <10kbyte + +http://paste.ubuntu.com/6123459/ <- pastebin of work-annex-copy-to-box.com-not-in-box.com-run11.log if it is of any use. + +"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment b/doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment new file mode 100644 index 000000000..99a0eb9ae --- /dev/null +++ b/doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.153.8.80" + subject="comment 9" + date="2013-09-28T19:34:42Z" + content=""" +Filed a bug on the DAV library about this: +"""]] diff --git a/doc/forum/MegaAnnex_not_working..mdwn b/doc/forum/MegaAnnex_not_working..mdwn deleted file mode 100644 index 3eff4b741..000000000 --- a/doc/forum/MegaAnnex_not_working..mdwn +++ /dev/null @@ -1,32 +0,0 @@ -When copying to a megaannex remote, it hangs after a while, and I get this: - - copy Boomarks/Android (gpg) Traceback (most recent call last): - File "/usr/local/bin//git-annex-remote-mega", line 511, in - common.startRemote() - File "/home/zack/megaannex/lib/CommonFunctions.py", line 557, in startRemote - sys.modules["__main__"].checkpresent(line) - File "/usr/local/bin//git-annex-remote-mega", line 483, in checkpresent - folder = setFolder(conf["folder"], common.ask("DIRHASH " + line[1])) - File "/usr/local/bin//git-annex-remote-mega", line 401, in setFolder - folder = createFolder(conf["folder"], 2) - File "/usr/local/bin//git-annex-remote-mega", line 378, in createFolder - res = m.create_folder(subject, folder) - File "/usr/lib/python2.7/site-packages/mega/mega.py", line 617, in create_folder - 'i': self.request_id}) - File "/usr/lib/python2.7/site-packages/mega/mega.py", line 110, in _api_request - timeout=self.timeout) - File "/usr/lib/python2.7/site-packages/requests/api.py", line 88, in post - return request('post', url, data=data, **kwargs) - File "/usr/lib/python2.7/site-packages/requests/api.py", line 44, in request - return session.request(method=method, url=url, **kwargs) - File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 354, in request - resp = self.send(prep, **send_kwargs) - File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 460, in send - r = adapter.send(request, **kwargs) - File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 250, in send - raise SSLError(e) - requests.exceptions.SSLError: The read operation timed out - (external special remote protocol error, unexpectedly received "" (unable to parse command)) failed - - -Any help would be appreciated, thanks! diff --git a/doc/forum/MegaAnnex_not_working./comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment b/doc/forum/MegaAnnex_not_working./comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment deleted file mode 100644 index c2e7353db..000000000 --- a/doc/forum/MegaAnnex_not_working./comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.2" - subject="comment 1" - date="2014-07-11T19:42:24Z" - content=""" -This looks to me like the connection to Mega fails, so either they have a server down, or a network problem, or perhaps the API that the megaannex remote was relying on might have been removed.. -"""]] diff --git a/doc/forum/MegaAnnex_not_working./comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment b/doc/forum/MegaAnnex_not_working./comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment deleted file mode 100644 index e9fd01f14..000000000 --- a/doc/forum/MegaAnnex_not_working./comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI" - nickname="Zack" - subject="comment 2" - date="2014-07-19T12:48:08Z" - content=""" -I believe it may have been removed, unfortunately. :( -"""]] diff --git a/doc/forum/MegaAnnex_not_working.mdwn b/doc/forum/MegaAnnex_not_working.mdwn new file mode 100644 index 000000000..3eff4b741 --- /dev/null +++ b/doc/forum/MegaAnnex_not_working.mdwn @@ -0,0 +1,32 @@ +When copying to a megaannex remote, it hangs after a while, and I get this: + + copy Boomarks/Android (gpg) Traceback (most recent call last): + File "/usr/local/bin//git-annex-remote-mega", line 511, in + common.startRemote() + File "/home/zack/megaannex/lib/CommonFunctions.py", line 557, in startRemote + sys.modules["__main__"].checkpresent(line) + File "/usr/local/bin//git-annex-remote-mega", line 483, in checkpresent + folder = setFolder(conf["folder"], common.ask("DIRHASH " + line[1])) + File "/usr/local/bin//git-annex-remote-mega", line 401, in setFolder + folder = createFolder(conf["folder"], 2) + File "/usr/local/bin//git-annex-remote-mega", line 378, in createFolder + res = m.create_folder(subject, folder) + File "/usr/lib/python2.7/site-packages/mega/mega.py", line 617, in create_folder + 'i': self.request_id}) + File "/usr/lib/python2.7/site-packages/mega/mega.py", line 110, in _api_request + timeout=self.timeout) + File "/usr/lib/python2.7/site-packages/requests/api.py", line 88, in post + return request('post', url, data=data, **kwargs) + File "/usr/lib/python2.7/site-packages/requests/api.py", line 44, in request + return session.request(method=method, url=url, **kwargs) + File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 354, in request + resp = self.send(prep, **send_kwargs) + File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 460, in send + r = adapter.send(request, **kwargs) + File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 250, in send + raise SSLError(e) + requests.exceptions.SSLError: The read operation timed out + (external special remote protocol error, unexpectedly received "" (unable to parse command)) failed + + +Any help would be appreciated, thanks! diff --git a/doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment b/doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment new file mode 100644 index 000000000..c2e7353db --- /dev/null +++ b/doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.2" + subject="comment 1" + date="2014-07-11T19:42:24Z" + content=""" +This looks to me like the connection to Mega fails, so either they have a server down, or a network problem, or perhaps the API that the megaannex remote was relying on might have been removed.. +"""]] diff --git a/doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment b/doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment new file mode 100644 index 000000000..e9fd01f14 --- /dev/null +++ b/doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI" + nickname="Zack" + subject="comment 2" + date="2014-07-19T12:48:08Z" + content=""" +I believe it may have been removed, unfortunately. :( +"""]] diff --git a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available..mdwn b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available..mdwn deleted file mode 100644 index 1f02b568c..000000000 --- a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available..mdwn +++ /dev/null @@ -1,36 +0,0 @@ -I noticed this in my log file... - -
-[2015-05-21 18:10:02 CDT] main: starting assistant version 5.20150508-gf71c23f
-(started...) gpg: keyring `/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg' created
-...
-[2015-05-21 18:10:02 CDT] Upgrader: Checking if an upgrade is available.
-...
-[2015-05-21 18:10:02 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150419-g900e1b6"]
-[2015-05-21 18:10:03 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
-gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
-gpg: Can't check signature: public key not found
-[2015-05-21 18:10:03 CDT] Upgrader: Failed to check if upgrade is available.
-
- -So I copied trustedkeys.gpg from the bundle folder to the MacOS folder, replacing the newly created trustedkeys.gpg and now I get this... which is better... ;-) - -
-[2015-05-21 18:17:24 CDT] main: starting assistant version 5.20150508-gf71c23f
-...
-[2015-05-21 18:17:25 CDT] Upgrader: Checking if an upgrade is available.
-...
-[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info","--user-agent","git-annex/5.20150508-gf71c23f"]
-...
-[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150508-gf71c23f"]
-[2015-05-21 18:17:25 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
-gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
-gpg: /var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
-gpg: Good signature from "git-annex distribution signing key (for Joey Hess) "
-gpg: WARNING: This key is not certified with a trusted signature!
-gpg:          There is no indication that the signature belongs to the owner.
-Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
-[2015-05-21 18:17:25 CDT] Upgrader: No new version found.
-
- -FYI diff --git a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment deleted file mode 100644 index 39eae02a8..000000000 --- a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-05-22T17:35:11Z" - content=""" -Aha, this is a path propel to the trustedkeys.gpg file, it's in bundle/ -in the OSX app, and git-annex tells gpg to look in the parent directory -instead. - -Fixed in git. Unfortunately I can't fix old versions of git-annex so -OSX users will need to manually upgrade to version 5.20150522 to get this -fix. -"""]] diff --git a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn new file mode 100644 index 000000000..1f02b568c --- /dev/null +++ b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn @@ -0,0 +1,36 @@ +I noticed this in my log file... + +
+[2015-05-21 18:10:02 CDT] main: starting assistant version 5.20150508-gf71c23f
+(started...) gpg: keyring `/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg' created
+...
+[2015-05-21 18:10:02 CDT] Upgrader: Checking if an upgrade is available.
+...
+[2015-05-21 18:10:02 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150419-g900e1b6"]
+[2015-05-21 18:10:03 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
+gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
+gpg: Can't check signature: public key not found
+[2015-05-21 18:10:03 CDT] Upgrader: Failed to check if upgrade is available.
+
+ +So I copied trustedkeys.gpg from the bundle folder to the MacOS folder, replacing the newly created trustedkeys.gpg and now I get this... which is better... ;-) + +
+[2015-05-21 18:17:24 CDT] main: starting assistant version 5.20150508-gf71c23f
+...
+[2015-05-21 18:17:25 CDT] Upgrader: Checking if an upgrade is available.
+...
+[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info","--user-agent","git-annex/5.20150508-gf71c23f"]
+...
+[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150508-gf71c23f"]
+[2015-05-21 18:17:25 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
+gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
+gpg: /var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) "
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-05-21 18:17:25 CDT] Upgrader: No new version found.
+
+ +FYI diff --git a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment new file mode 100644 index 000000000..39eae02a8 --- /dev/null +++ b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-05-22T17:35:11Z" + content=""" +Aha, this is a path propel to the trustedkeys.gpg file, it's in bundle/ +in the OSX app, and git-annex tells gpg to look in the parent directory +instead. + +Fixed in git. Unfortunately I can't fix old versions of git-annex so +OSX users will need to manually upgrade to version 5.20150522 to get this +fix. +"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too..mdwn b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too..mdwn deleted file mode 100644 index 37dd1bc24..000000000 --- a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too..mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I use git everywhere i can to manage versions, but I have a usecase that is probably very common, but i could not see in the howto lists. - -I have a shared fileserver(FS) that is managed by others and is full of the equivalent of binary blobs (media, word docs etc). Binary blobs of course are something that git cannot normally do anything meaningful with. That is diff/patch for managing the evolution of any given file. Binary blobs have a different lifecycle of course, and i see annex as the solution for managing that. - -The remote FS is being used as an SMB server to windows and linux clients. The FS has other capabilities that i can use other than SMB mount including rsync and ssh. As it is running samba it also uses symlinks underneath the the SMB to manage shared folders, which can be seen when mounted in unix mode. This means the FS landscape is different when using samba as compared to rsync and ssh, as some paths may be symlinked in. The symlinks should not effect this use case, but I mention them because I don't know how annex would manage this. - -The basic scenario is that i have a set of project files and folders in tree on the remote FS. I want to use git to pull these binary files from the FS to edit locally while also seein/capturing changes made to files in that tree by other people not using git. Then i want to push my edits back, without effecting the files that i have no responsibility for (but have write access to). - -Think a team of people with various technical capabilities working on changing binary blobs in this remote directory tree. I want to manage my interactions with portions of that remote FS tree via git (annex) with a local mirror (preferably actually containing only the files i care about) so that i can manipulate them locally, clone to other work machines and generally play about with and then push back while watching the whole tree and capturing changes others make (during sync/merge/push/pull?). Because i do not manage it, or own the contents, i also need to be able to maintain the some of the permissions (guid/uid) of the remote and untouched files. - -Can you give me any suggestions? diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_1_30205c1ba18e5dca2314f593e1a0e236._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_1_30205c1ba18e5dca2314f593e1a0e236._comment deleted file mode 100644 index 7f170975a..000000000 --- a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_1_30205c1ba18e5dca2314f593e1a0e236._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkI9pq1WH6MWeExXHVQVEsniT3DdFv4AB8" - nickname="Roberto" - subject="My usecase too" - date="2014-01-12T23:43:18Z" - content=""" -Just wanted to thank your for describing my very same use case. Unfortunately I still haven't wrapped my head around git annex to accommodate such scenario. -"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_2_f8df728de28218a6b060ae9f08adac79._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_2_f8df728de28218a6b060ae9f08adac79._comment deleted file mode 100644 index 576007b62..000000000 --- a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_2_f8df728de28218a6b060ae9f08adac79._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~timo-linux" - nickname="Tim O'Callaghan" - subject="Would GIT_DIR or GIT_WORK_TREE be valid for this?" - date="2014-01-14T07:29:31Z" - content=""" -For example if i mounted this filesystem and used annex and GIT_ env variables to watch it? Presumably in direct mode, because i don't want to remove the source files, but i do want to manage my source files. -"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_3_ba438b3a371261ee841665f1ae57eba2._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_3_ba438b3a371261ee841665f1ae57eba2._comment deleted file mode 100644 index 9184495b5..000000000 --- a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_3_ba438b3a371261ee841665f1ae57eba2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~timo-linux" - nickname="Tim O'Callaghan" - subject="What about annex mirror? " - date="2014-01-14T08:00:42Z" - content=""" -I cannot find any documentation on it, is it appropriate for this situation? -"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_4_9f72e6c7c14a77330297526aef260762._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_4_9f72e6c7c14a77330297526aef260762._comment deleted file mode 100644 index d43019ce0..000000000 --- a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_4_9f72e6c7c14a77330297526aef260762._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="http://cstork.org/" - nickname="Chris Stork" - subject="Many peoples' use case" - date="2014-01-14T09:39:05Z" - content=""" -Well, a description of this use case is posted every few weeks in different forms. Here are two, including my own: ;-) - -* [[Using git annex with a SMB 47 FTP TV NAS with preconfigured dirs]] -* [[Direct special remotes]] -"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment deleted file mode 100644 index 321fa9c53..000000000 --- a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too./comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~timo-linux" - nickname="Tim O'Callaghan" - subject="Still have not found a reasonable solution for this myself." - date="2014-02-03T14:34:14Z" - content=""" -And it seems i'm not the only one, So I'd like to bump the topic. - -Can someone at least tell me if it is possible with annex/annex-gui or not? -"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn new file mode 100644 index 000000000..37dd1bc24 --- /dev/null +++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn @@ -0,0 +1,11 @@ +I use git everywhere i can to manage versions, but I have a usecase that is probably very common, but i could not see in the howto lists. + +I have a shared fileserver(FS) that is managed by others and is full of the equivalent of binary blobs (media, word docs etc). Binary blobs of course are something that git cannot normally do anything meaningful with. That is diff/patch for managing the evolution of any given file. Binary blobs have a different lifecycle of course, and i see annex as the solution for managing that. + +The remote FS is being used as an SMB server to windows and linux clients. The FS has other capabilities that i can use other than SMB mount including rsync and ssh. As it is running samba it also uses symlinks underneath the the SMB to manage shared folders, which can be seen when mounted in unix mode. This means the FS landscape is different when using samba as compared to rsync and ssh, as some paths may be symlinked in. The symlinks should not effect this use case, but I mention them because I don't know how annex would manage this. + +The basic scenario is that i have a set of project files and folders in tree on the remote FS. I want to use git to pull these binary files from the FS to edit locally while also seein/capturing changes made to files in that tree by other people not using git. Then i want to push my edits back, without effecting the files that i have no responsibility for (but have write access to). + +Think a team of people with various technical capabilities working on changing binary blobs in this remote directory tree. I want to manage my interactions with portions of that remote FS tree via git (annex) with a local mirror (preferably actually containing only the files i care about) so that i can manipulate them locally, clone to other work machines and generally play about with and then push back while watching the whole tree and capturing changes others make (during sync/merge/push/pull?). Because i do not manage it, or own the contents, i also need to be able to maintain the some of the permissions (guid/uid) of the remote and untouched files. + +Can you give me any suggestions? diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment new file mode 100644 index 000000000..7f170975a --- /dev/null +++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkI9pq1WH6MWeExXHVQVEsniT3DdFv4AB8" + nickname="Roberto" + subject="My usecase too" + date="2014-01-12T23:43:18Z" + content=""" +Just wanted to thank your for describing my very same use case. Unfortunately I still haven't wrapped my head around git annex to accommodate such scenario. +"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment new file mode 100644 index 000000000..576007b62 --- /dev/null +++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://launchpad.net/~timo-linux" + nickname="Tim O'Callaghan" + subject="Would GIT_DIR or GIT_WORK_TREE be valid for this?" + date="2014-01-14T07:29:31Z" + content=""" +For example if i mounted this filesystem and used annex and GIT_ env variables to watch it? Presumably in direct mode, because i don't want to remove the source files, but i do want to manage my source files. +"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment new file mode 100644 index 000000000..9184495b5 --- /dev/null +++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://launchpad.net/~timo-linux" + nickname="Tim O'Callaghan" + subject="What about annex mirror? " + date="2014-01-14T08:00:42Z" + content=""" +I cannot find any documentation on it, is it appropriate for this situation? +"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment new file mode 100644 index 000000000..d43019ce0 --- /dev/null +++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://cstork.org/" + nickname="Chris Stork" + subject="Many peoples' use case" + date="2014-01-14T09:39:05Z" + content=""" +Well, a description of this use case is posted every few weeks in different forms. Here are two, including my own: ;-) + +* [[Using git annex with a SMB 47 FTP TV NAS with preconfigured dirs]] +* [[Direct special remotes]] +"""]] diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment new file mode 100644 index 000000000..321fa9c53 --- /dev/null +++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://launchpad.net/~timo-linux" + nickname="Tim O'Callaghan" + subject="Still have not found a reasonable solution for this myself." + date="2014-02-03T14:34:14Z" + content=""" +And it seems i'm not the only one, So I'd like to bump the topic. + +Can someone at least tell me if it is possible with annex/annex-gui or not? +"""]] diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory..mdwn b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory..mdwn deleted file mode 100644 index ea0ad80ba..000000000 --- a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory..mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I tried to "git annex copy --to SSH-REMOTE" it says it sends it: -copy Test (checking SSH-REMOTE...) (to SSH-REMOTE...) -SHA256E-s6--8283daccd02d2b2797da53446d367e39dc0fb1615bcae4274460f44455bd9822 - 6 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/1) - -sent 146 bytes received 31 bytes 354.00 bytes/sec -total size is 6 speedup is 0.03 -ok -(Recording state in git...) - -But I can't find it in the working directory. Can anyone help me? diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment deleted file mode 100644 index 18c41f1c9..000000000 --- a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="http://www.rfc1149.net/" - nickname="Sam" - subject="comment 1" - date="2013-08-05T09:49:56Z" - content=""" -`git annex copy` will only push objects (content) into git annex private directory. You have to issue a `git annex merge` (or `git annex sync`) on the receiving end, or run `git annex assistant` there to update the working directory. - -Note that you can run `git annex merge` as a post-update hook if you want this to be done automatically. - -"""]] diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_2_c18083d9054f66f0bd51d63452af07eb._comment b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_2_c18083d9054f66f0bd51d63452af07eb._comment deleted file mode 100644 index da0a86929..000000000 --- a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory./comment_2_c18083d9054f66f0bd51d63452af07eb._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI" - nickname="Zack" - subject="It worked!" - date="2013-08-05T09:57:25Z" - content=""" -Thanks for the help, it worked. -"""]] diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn new file mode 100644 index 000000000..ea0ad80ba --- /dev/null +++ b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn @@ -0,0 +1,11 @@ +I tried to "git annex copy --to SSH-REMOTE" it says it sends it: +copy Test (checking SSH-REMOTE...) (to SSH-REMOTE...) +SHA256E-s6--8283daccd02d2b2797da53446d367e39dc0fb1615bcae4274460f44455bd9822 + 6 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/1) + +sent 146 bytes received 31 bytes 354.00 bytes/sec +total size is 6 speedup is 0.03 +ok +(Recording state in git...) + +But I can't find it in the working directory. Can anyone help me? diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment new file mode 100644 index 000000000..18c41f1c9 --- /dev/null +++ b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://www.rfc1149.net/" + nickname="Sam" + subject="comment 1" + date="2013-08-05T09:49:56Z" + content=""" +`git annex copy` will only push objects (content) into git annex private directory. You have to issue a `git annex merge` (or `git annex sync`) on the receiving end, or run `git annex assistant` there to update the working directory. + +Note that you can run `git annex merge` as a post-update hook if you want this to be done automatically. + +"""]] diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment new file mode 100644 index 000000000..da0a86929 --- /dev/null +++ b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI" + nickname="Zack" + subject="It worked!" + date="2013-08-05T09:57:25Z" + content=""" +Thanks for the help, it worked. +"""]] diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer..mdwn b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer..mdwn deleted file mode 100644 index 1e2e44cfa..000000000 --- a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer..mdwn +++ /dev/null @@ -1,3 +0,0 @@ -A couple times working in an annex manually, I accidentally did "git add" instead of "git annex add" and ended up with files checked into my repo instead of symlinks. So now there is some file content in git, rather than in the annex. Is there any way to root that out, or is it there forever? (My limited knowledge of git says: it's there forever, unless maybe you go into the branches where it lives, do an interactive rebase to the time before it was added, remove that commit, replay history, and then garbage collect, but I have no idea if that would suddenly break git annex, and it sounds painful anyway.) - -If say I were a neat freak and wanted to just start over with a clean annex, I imagine the thing to do would be to just start the hell over -- and if I wanted to do that, the way to go would be to get into a full repository, do a "git annex uninit" and then throw away the .git directory, then do "git init" and "git annex init" and then "git annex add ." ? diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_1_752db25abb647804a1cc12c5b247378a._comment b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_1_752db25abb647804a1cc12c5b247378a._comment deleted file mode 100644 index 486d43480..000000000 --- a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_1_752db25abb647804a1cc12c5b247378a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.6.49" - subject="comment 1" - date="2012-12-02T05:41:56Z" - content=""" -You can rebase or use git-filter-branch to rewrite history. As long as you don't touch the git-annex branch, git-annex won't care, at all. Have at it! - -Your uninit plan would also work. -"""]] diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment deleted file mode 100644 index 9c7f35a77..000000000 --- a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer./comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://edheil.wordpress.com/" - ip="173.162.44.162" - subject="comment 2" - date="2012-12-03T15:46:48Z" - content=""" -Thanks! I ended up going with the uninit plan. -"""]] diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn new file mode 100644 index 000000000..1e2e44cfa --- /dev/null +++ b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn @@ -0,0 +1,3 @@ +A couple times working in an annex manually, I accidentally did "git add" instead of "git annex add" and ended up with files checked into my repo instead of symlinks. So now there is some file content in git, rather than in the annex. Is there any way to root that out, or is it there forever? (My limited knowledge of git says: it's there forever, unless maybe you go into the branches where it lives, do an interactive rebase to the time before it was added, remove that commit, replay history, and then garbage collect, but I have no idea if that would suddenly break git annex, and it sounds painful anyway.) + +If say I were a neat freak and wanted to just start over with a clean annex, I imagine the thing to do would be to just start the hell over -- and if I wanted to do that, the way to go would be to get into a full repository, do a "git annex uninit" and then throw away the .git directory, then do "git init" and "git annex init" and then "git annex add ." ? diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment new file mode 100644 index 000000000..486d43480 --- /dev/null +++ b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.6.49" + subject="comment 1" + date="2012-12-02T05:41:56Z" + content=""" +You can rebase or use git-filter-branch to rewrite history. As long as you don't touch the git-annex branch, git-annex won't care, at all. Have at it! + +Your uninit plan would also work. +"""]] diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment new file mode 100644 index 000000000..9c7f35a77 --- /dev/null +++ b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://edheil.wordpress.com/" + ip="173.162.44.162" + subject="comment 2" + date="2012-12-03T15:46:48Z" + content=""" +Thanks! I ended up going with the uninit plan. +"""]] diff --git a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src..mdwn b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src..mdwn deleted file mode 100644 index ff9d1b6c7..000000000 --- a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src..mdwn +++ /dev/null @@ -1,12 +0,0 @@ -Total newbie here, so I apologize in advice for asking dumb questions. I did my best to look through the branchable docs, Google, etc to no avail. -I'm trying to use git-annex to manage my music collection (on Windows). I added and pushed 669 songs to GitLab from my desktop. -At this point, my music is on both the first folder and GitLab (worth noting that I still don't know where to find the binaries on GitLab...). - -Then just as a test, tried to clone the repo and run `git annex sync --content`. - -I get the following error: -`error: dst ref refs/heads/synced/git-annex receives from more than one src.` -`error: failed to push some refs to 'git@gitlab.com:repolocation/Songs.git'` - -I figure it's because the files are both on GitLab and the other folder, but I'm not sure how to proceed. -Would appreciate any help, thanks! diff --git a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src./comment_1_c805561fa714ff3930742bb330b340c9._comment b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src./comment_1_c805561fa714ff3930742bb330b340c9._comment deleted file mode 100644 index 3f4be57a6..000000000 --- a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src./comment_1_c805561fa714ff3930742bb330b340c9._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-09T18:47:17Z" - content=""" -This error message is a `git push` error message. -I've never seen this error before.. - - -Shows one way to get into this situation, where a repository somehow has -a tag with the same name as the branch that is being pushed. - -> -Similarly shows it being a conflict between a tag and a branch; -this time the tag exists in the local repository. - -I guess you've run into some problem like this. If there's an easy way to -reproduce the problem using just git-annex commands, and not manaul tag -creation etc, please file a bug report with details. -"""]] diff --git a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn new file mode 100644 index 000000000..ff9d1b6c7 --- /dev/null +++ b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn @@ -0,0 +1,12 @@ +Total newbie here, so I apologize in advice for asking dumb questions. I did my best to look through the branchable docs, Google, etc to no avail. +I'm trying to use git-annex to manage my music collection (on Windows). I added and pushed 669 songs to GitLab from my desktop. +At this point, my music is on both the first folder and GitLab (worth noting that I still don't know where to find the binaries on GitLab...). + +Then just as a test, tried to clone the repo and run `git annex sync --content`. + +I get the following error: +`error: dst ref refs/heads/synced/git-annex receives from more than one src.` +`error: failed to push some refs to 'git@gitlab.com:repolocation/Songs.git'` + +I figure it's because the files are both on GitLab and the other folder, but I'm not sure how to proceed. +Would appreciate any help, thanks! diff --git a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment new file mode 100644 index 000000000..3f4be57a6 --- /dev/null +++ b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-09-09T18:47:17Z" + content=""" +This error message is a `git push` error message. +I've never seen this error before.. + + +Shows one way to get into this situation, where a repository somehow has +a tag with the same name as the branch that is being pushed. + +> +Similarly shows it being a conflict between a tag and a branch; +this time the tag exists in the local repository. + +I guess you've run into some problem like this. If there's an easy way to +reproduce the problem using just git-annex commands, and not manaul tag +creation etc, please file a bug report with details. +"""]] diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes..mdwn b/doc/todo/Set_total_storage_limit_for_special_remotes..mdwn deleted file mode 100644 index 2b66e9828..000000000 --- a/doc/todo/Set_total_storage_limit_for_special_remotes..mdwn +++ /dev/null @@ -1 +0,0 @@ -I'd like to be able to set a fixed limit on how much storage can be uploaded to a special remote. A use case for this may be that I want to spend no more than Y dollars, on a storage service that charges $X per gigabyte. I would thus set a limit where I a upload would be interrupted with a warning about the limit, and to continue I would need to use a --force option. diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment b/doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment deleted file mode 100644 index 0df5669d6..000000000 --- a/doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-07-02T20:01:42Z" - content=""" -This totally makes sense to want, but it's rather difficult to implement since -multiple git-annex repos can all be uploading content to the same special -remote, while disconnected from each other. -"""]] diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment b/doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment deleted file mode 100644 index 818b7f386..000000000 --- a/doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="mawillcockson" - subject="comment 2" - date="2015-07-18T19:13:03Z" - content=""" -Perhaps server-side [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)? - -Maybe a git hook script that uses [inotify](https://en.wikipedia.org/wiki/Inotify) for inode size notifications. - -I would have no idea how to implement this, though. -"""]] diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes.mdwn b/doc/todo/Set_total_storage_limit_for_special_remotes.mdwn new file mode 100644 index 000000000..2b66e9828 --- /dev/null +++ b/doc/todo/Set_total_storage_limit_for_special_remotes.mdwn @@ -0,0 +1 @@ +I'd like to be able to set a fixed limit on how much storage can be uploaded to a special remote. A use case for this may be that I want to spend no more than Y dollars, on a storage service that charges $X per gigabyte. I would thus set a limit where I a upload would be interrupted with a warning about the limit, and to continue I would need to use a --force option. diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment new file mode 100644 index 000000000..0df5669d6 --- /dev/null +++ b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-07-02T20:01:42Z" + content=""" +This totally makes sense to want, but it's rather difficult to implement since +multiple git-annex repos can all be uploading content to the same special +remote, while disconnected from each other. +"""]] diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment new file mode 100644 index 000000000..818b7f386 --- /dev/null +++ b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="mawillcockson" + subject="comment 2" + date="2015-07-18T19:13:03Z" + content=""" +Perhaps server-side [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)? + +Maybe a git hook script that uses [inotify](https://en.wikipedia.org/wiki/Inotify) for inode size notifications. + +I would have no idea how to implement this, though. +"""]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files..mdwn b/doc/todo/Slow_transfer_for_a_lot_of_small_files..mdwn deleted file mode 100644 index 00cdad0fe..000000000 --- a/doc/todo/Slow_transfer_for_a_lot_of_small_files..mdwn +++ /dev/null @@ -1,20 +0,0 @@ -What steps will reproduce the problem? -Sync a lot of small files. - -What is the expected output? What do you see instead? -The expected output is hopefully a fast transfer. - -But currently it seems like git-annex is only using one thread to transfer(per host or total?) - -An option to select number of transfer threads to use(possibly per host) would be very nice. - -> Opening a lot of connections to a single host is probably not desirable. -> -> I do want to do something to allow slow hosts to not hold up transfers to -> other hosts, which might involve running multiple queued transfers at -> once. The webapp already allows the user to force a given transfer to -> happen immediately. --[[Joey]] - -And maybe also an option to limit how long a queue the browser should show, it can become quite resource intensive with a long queue. - -> The queue is limited to 20 items for this reason. --[[Joey]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment b/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment deleted file mode 100644 index c877f9359..000000000 --- a/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnKT33H9qVVGJOybP00Zq2NZmNAyB65mic" - nickname="Lucas" - subject="comment 1" - date="2014-11-12T07:58:07Z" - content=""" -Opening multiple connections to a host can be preferable sometimes and it's unlikely to be an issue at all for the larger remotes like Google, Microsoft or S3. - -For example, the OneDrive provider spends a lot of time sitting around waiting for initialisation between uploads. Using, say 5 threads instead of 1 would allow it to continue doing things while it waits. - -Multiple connections can also vastly improve upload speeds for users with congested home internet connections. -"""]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment b/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment deleted file mode 100644 index d531914ab..000000000 --- a/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~krastanov-stefan" - nickname="krastanov-stefan" - subject="Status of this issue" - date="2014-12-27T15:18:42Z" - content=""" -I was unable to find a way to tell git-annex that certain remotes should receive multiple transfers in parallel. Is this implemented yet or on the roadmap? If neither would modifying the webapp to bear this logic without touching git-annex itself be a solution (asking mainly because it can be done with a greasemonkey script)? -"""]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files.mdwn b/doc/todo/Slow_transfer_for_a_lot_of_small_files.mdwn new file mode 100644 index 000000000..00cdad0fe --- /dev/null +++ b/doc/todo/Slow_transfer_for_a_lot_of_small_files.mdwn @@ -0,0 +1,20 @@ +What steps will reproduce the problem? +Sync a lot of small files. + +What is the expected output? What do you see instead? +The expected output is hopefully a fast transfer. + +But currently it seems like git-annex is only using one thread to transfer(per host or total?) + +An option to select number of transfer threads to use(possibly per host) would be very nice. + +> Opening a lot of connections to a single host is probably not desirable. +> +> I do want to do something to allow slow hosts to not hold up transfers to +> other hosts, which might involve running multiple queued transfers at +> once. The webapp already allows the user to force a given transfer to +> happen immediately. --[[Joey]] + +And maybe also an option to limit how long a queue the browser should show, it can become quite resource intensive with a long queue. + +> The queue is limited to 20 items for this reason. --[[Joey]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment b/doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment new file mode 100644 index 000000000..c877f9359 --- /dev/null +++ b/doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnKT33H9qVVGJOybP00Zq2NZmNAyB65mic" + nickname="Lucas" + subject="comment 1" + date="2014-11-12T07:58:07Z" + content=""" +Opening multiple connections to a host can be preferable sometimes and it's unlikely to be an issue at all for the larger remotes like Google, Microsoft or S3. + +For example, the OneDrive provider spends a lot of time sitting around waiting for initialisation between uploads. Using, say 5 threads instead of 1 would allow it to continue doing things while it waits. + +Multiple connections can also vastly improve upload speeds for users with congested home internet connections. +"""]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment b/doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment new file mode 100644 index 000000000..d531914ab --- /dev/null +++ b/doc/todo/Slow_transfer_for_a_lot_of_small_files/comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://launchpad.net/~krastanov-stefan" + nickname="krastanov-stefan" + subject="Status of this issue" + date="2014-12-27T15:18:42Z" + content=""" +I was unable to find a way to tell git-annex that certain remotes should receive multiple transfers in parallel. Is this implemented yet or on the roadmap? If neither would modifying the webapp to bear this logic without touching git-annex itself be a solution (asking mainly because it can be done with a greasemonkey script)? +"""]] diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule..mdwn b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule..mdwn deleted file mode 100644 index 8166479b8..000000000 --- a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule..mdwn +++ /dev/null @@ -1,32 +0,0 @@ -During the campaign adding a chunking feature to obscure filesize for encrypted files was added to the roadmap. But there is still one potentially valuable set* of data that git-annex can help obscure: when you access your remotes. - -This data can be used to determine when a user is actively using a remote, but if a remote is always accessed at the same time that data becomes less useful. Somebody could still monitor total traffic over a long period and figure out that a remote was more active in a given week or month, but scheduling reduces the resolution of your access times and their data. Maybe this isn't the most important feature to add, but it would be nice to have, and could possibly be built on top of the existing git-annex scheduler. It could work by queuing inter-remote transactions ('get', 'copy', 'sync', etc.), so that jobs start at the same time every day, or even the same time and day every week. - -Possible syntax examples: -###Setting up the schedule: -git annex queue schedule Monday:1730 (starts every monday at 5:30PM) - -git annex queue schedule 1400 (starts every day at 2PM) - -###Queuing git-annex commands: -git annex queue prepend sync (pretends 'sync' to the very front of the queue) - -git annex queue append get file.ISO (appends to queue file.ISO for retrieval from a repo) - -###Viewing/editing queue: -git annex queue view (view the current queue, jobs displayed with corresponding numbers) - -git annex queue rm 20 (removes job 20 from queue) - - -\*The four I can think of are: - -* File contents (solved by crypto) - -* File size (solved on the remote by chunking, but total traffic usage can't be helped) - -* User IP/Remote IP (solved by VPN - outside scope of git-annex, unless someone writes a plugin) - -* Access times (obscured by a queue and scheduling) - -Note, there is a [[git-annex-schedule]] command now, but it only does `fsck`. diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule./comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule./comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment deleted file mode 100644 index df273afb2..000000000 --- a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule./comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - subject="how does the queue get built now?" - date="2015-04-28T21:32:36Z" - content=""" -how does the queue get created now? is it random or is there some deterministic thing that could be abuse to prioritise some content already (say alphabetical order or some similar hack)? - -the scheduling I think i can work around with clunky cron jobs to start/stop the assistant, but the queue I feel is a different beast. would you be available for hire to implement this feature in priority? - -thanks! -"""]] diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn new file mode 100644 index 000000000..8166479b8 --- /dev/null +++ b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn @@ -0,0 +1,32 @@ +During the campaign adding a chunking feature to obscure filesize for encrypted files was added to the roadmap. But there is still one potentially valuable set* of data that git-annex can help obscure: when you access your remotes. + +This data can be used to determine when a user is actively using a remote, but if a remote is always accessed at the same time that data becomes less useful. Somebody could still monitor total traffic over a long period and figure out that a remote was more active in a given week or month, but scheduling reduces the resolution of your access times and their data. Maybe this isn't the most important feature to add, but it would be nice to have, and could possibly be built on top of the existing git-annex scheduler. It could work by queuing inter-remote transactions ('get', 'copy', 'sync', etc.), so that jobs start at the same time every day, or even the same time and day every week. + +Possible syntax examples: +###Setting up the schedule: +git annex queue schedule Monday:1730 (starts every monday at 5:30PM) + +git annex queue schedule 1400 (starts every day at 2PM) + +###Queuing git-annex commands: +git annex queue prepend sync (pretends 'sync' to the very front of the queue) + +git annex queue append get file.ISO (appends to queue file.ISO for retrieval from a repo) + +###Viewing/editing queue: +git annex queue view (view the current queue, jobs displayed with corresponding numbers) + +git annex queue rm 20 (removes job 20 from queue) + + +\*The four I can think of are: + +* File contents (solved by crypto) + +* File size (solved on the remote by chunking, but total traffic usage can't be helped) + +* User IP/Remote IP (solved by VPN - outside scope of git-annex, unless someone writes a plugin) + +* Access times (obscured by a queue and scheduling) + +Note, there is a [[git-annex-schedule]] command now, but it only does `fsck`. diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment new file mode 100644 index 000000000..df273afb2 --- /dev/null +++ b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="anarcat" + subject="how does the queue get built now?" + date="2015-04-28T21:32:36Z" + content=""" +how does the queue get created now? is it random or is there some deterministic thing that could be abuse to prioritise some content already (say alphabetical order or some similar hack)? + +the scheduling I think i can work around with clunky cron jobs to start/stop the assistant, but the queue I feel is a different beast. would you be available for hire to implement this feature in priority? + +thanks! +"""]] -- cgit v1.2.3