This is more of a mini-tip or self-answered question: What to do when git-annex says "... (transfer already in progress, or unable to take transfer lock)" when trying to transfer a file to a special remote.
If you are sure that there are no other git-annex processes trying to upload (i.e. you cancelled it but git-annex crashed in the middle or something), have a look at .git/annex/transfer/upload/
. This is only for when you can't get them to be copied by re-running the git-annex command, only for when subsequent calls don't fix it. Intermittent issues might be caused by multiple jobs, so dropping the --jobs
parameter should fix those.
In my case I had two keys that git-annex refused to copy to a special remote no matter what I did and those dirs contained files named after the keys + ones with lck.
prefix. After removing those dirs, the upload went through as expected.
Hope this helps someone
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.
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:
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.