From 80ee1bcf7114d0f7483d6d5b79b8fb1e5921b970 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 5 Feb 2016 13:03:43 -0400 Subject: [PATCH] followup --- ...5_e33957c5a75b06d77b188a10b69a39fd._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/bugs/Unable_to_take_transfer_lock/comment_5_e33957c5a75b06d77b188a10b69a39fd._comment 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 0000000000..89ac13197d --- /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. +"""]]