forum/How to fix: (transfer already in progress, or git-annexhttp://git-annex.branchable.com/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/git-annexikiwiki2021-07-31T23:59:12Zcomment 1http://git-annex.branchable.com/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_1_345a7439720e8dc2cc6cb5eed6bcf73f/joey2021-04-22T23:16:27Z2021-04-05T19:38:17Z
<p>The only way I know of that this can perhaps happen is if you have
a remote accessed over ssh, and you are uploading to it, and ctrl-c
git-annex and then start the upload again. In that case, it's the remote
git-annex that complains about the transfer lock, and that happens because
sometimes the ctrl-c doesn't immediately stop the remote git-annex-shell
process. But if this were the case, deleting the local directory wouldn't
help, it would be the remote repo's directory you'd need to mess with, or
better just stop that git-annex-shell process.</p>
<p>Otherwise, it's true that the lock files for transfers live in that directory,
and deleting it is safe enough. However, the way git-annex uses locks should
not suffer from stale lock files normally. A few cases where I guess it
could:</p>
<ul>
<li>When annex.pidlock is set</li>
<li>Maybe when using NFS</li>
<li>Windows maybe?</li>
<li>Older versions of git-annex could get confused with --jobs when
several worktree files used the same key, but that's been fixed for a
while.</li>
</ul>
<p>Otherwise, it seems much more likely that you still had a git-annex process
that you didn't notice holding the lock open, than it does that your OS is
letting stale fcntl locks linger around after a process exits.</p>
comment 2http://git-annex.branchable.com/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_2_55ad844ee650a6a5026fdf5764dd9470/mattplasmastrike2021-07-31T23:59:12Z2021-07-31T23:59:12Z
<ul>
<li>I was also affected by this and removing everything in the transfer folder "rm -rf ./.git/annex/transfer/*" on both devices fixed the issue for me.</li>
<li>I sure I could have fixed this with a more surgical operation by selectively deleting files or maybe a command that I do not know</li>
<li>although I am not sure what caused it I was canceling the progress with "control c"</li>
</ul>