From b7500b21170b92b09fb76694ae7bd4ca7544e850 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 5 Feb 2016 13:03:43 -0400 Subject: followup --- ...comment_5_e33957c5a75b06d77b188a10b69a39fd._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment (limited to 'doc/bugs/Unable_to_take_transfer_lock') diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment new file mode 100644 index 000000000..89ac13197 --- /dev/null +++ b/doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2016-02-05T17:01:24Z" + content=""" +@luca you might get that with -J2 if you have two work tree files that +point to the same key. The first thread will start copying the first file, +and then the second thread tries to copy the second file but sees the key +is already being copied. + +It shouldn't happen otherwise; the way -J works is it splits files between +threads. So, no two threads will be working on the same file, except in the +situation described above. + +I doubt that whatever you're seeing is the same problem originally +described in this bug report. I'm still waiting for a followup with missing +information about the originally described bug. +"""]] -- cgit v1.2.3