diff options
author | Joey Hess <joeyh@joeyh.name> | 2016-02-09 11:56:23 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2016-02-09 11:56:23 -0400 |
commit | e6c7e3471f6aac0f3d4cb32a5b316df5ab7fc118 (patch) | |
tree | f6c00eeefb1af89d8a5869b1559711d873d47360 | |
parent | bc923198dda388a90ba82225d6aa9fc2b75b907d (diff) | |
parent | c11be022a39090746deeaebe30339a124c734593 (diff) |
Merge branch 'master' of ssh://git-annex.branchable.com
2 files changed, 36 insertions, 0 deletions
diff --git a/doc/bugs/Adding_torrent_via_addurl_fails/comment_2_e317aee1ff6e60aafcd106751af660c8._comment b/doc/bugs/Adding_torrent_via_addurl_fails/comment_2_e317aee1ff6e60aafcd106751af660c8._comment new file mode 100644 index 000000000..6b4a52478 --- /dev/null +++ b/doc/bugs/Adding_torrent_via_addurl_fails/comment_2_e317aee1ff6e60aafcd106751af660c8._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="annuges" + subject="comment 2" + date="2016-02-09T13:49:42Z" + content=""" +sorry looks like i hadd a litle mixup, the full magnet link that i used when checking btshowmetainfo was + + magnet:?xt=urn:btih:88066b90278f2de655ee2dd44e784c340b54e45c&dn=archlinux-2016.02.01-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce + +Using this one with aria2c --bt-save-metadata results in a torrent file with the announce-list entry only. +Modifying the link to only contain one tracker url still results in an announce-list with a single entry. + +There also is a separate torrent file on the arch website that has the announce field set correctly. + + https://www.archlinux.org/releng/releases/2016.02.01/torrent/ + +They hide the actuall .torrent file though so addurl doesn't trigger the torrent parsing with led me to try the magnet link to begin with. + +Anyway, looks like aria2c is at fault because it doesn't generate standard compliant .torrent files from magnet links. + + + + +"""]] diff --git a/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment new file mode 100644 index 000000000..8687f9eae --- /dev/null +++ b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="rpglover64@acd6753c831cc132736943bec350391fcb2ff77d" + nickname="rpglover64" + subject="Third time's the charm?" + date="2016-02-08T20:44:11Z" + content=""" +So I tried again (I got read-write access to the top level of the directory I want to share, so creating a .git was straightforward), and I had two things get in my way. I have a lot of relatively large files (~10,000), so I decided to use the WORM backend rather than waiting for the SHA to complete. Even so, adding everything was slow-going. + +Since the most interesting feature of git-annex is queueing up downloads to sync on LAN, is there a way to add the files especially quickly by sacrificing some more safety? Essentially, I want to use git-annex as a glorified file server, letting my laptop do all the interesting work. + +Second, when I Ctrl-C during `git annex add`, progress is not preserved in a direct-mode repository, so the add needs to start all over again. +"""]] |