From e9fc1109dc6627a6bed12797339dc3139878296e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 30 Nov 2015 15:50:55 -0400 Subject: um --- ...mment_1_4eff7f261659202084d32e068b93f77b._comment | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment diff --git a/doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment b/doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment new file mode 100644 index 000000000..3db482bc1 --- /dev/null +++ b/doc/bugs/Unable_to_take_transfer_lock/comment_1_4eff7f261659202084d32e068b93f77b._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-11-30T19:46:05Z" + content=""" +The most likely reason for that error message would be if a transfer +of the same file was already in progress by another git-annex process. + +It might also be the case that if you're trying to access a git-annex +repository via SMB, the POSIX fcntl locking that git-annex needs to do +don't work. This is often the case with various network filesystems. +Solution is to make the url for the git remote be a ssh:// url instead. + +I don't know what OSX's case-insensative complication could have to do with +this, although it certianly seems to be a good way to get completely +unexpected behavior. + +Is there an actual bug here? What are the steps to reproduce +it? +"""]] -- cgit v1.2.3