Please describe the problem.
This is a weird one. I'm getting rsync protocol version mismatch -- is your shell clean? on a particular file.
I have tried to reproduce it but not been able.
- First time it happened, I went to the problem repo and did a
get, which worked, destroying the evidence. "Luckily", this happened again a few days later. - I thought maybe it was because there was a partial transfer in
.git/annex/tmpwith some specific characteristics. Nope, if I remove the file intmpthe problem remains. - I made another clone think it was the problem repo, transferred the file to that repo, no problem. Dropped it, pointed everything back to the original bad repo. Still bad.
- Both sides are running
rsync version 3.1.0 protocol version 31.
What steps will reproduce the problem?
Working on it. But I want to put the preliminaries here, in case someone else has seen this.
What version of git-annex are you using? On what operating system?
Both sides are running git-annex version: 5.20150508-g883d57f, on Ubuntu 14.04.2 LTS.
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
$ git annex copy --to acozed claes/colt/20150511_174818.jpg
copy claes/colt/20150511_174818.jpg (checking acozed...) (to acozed...)
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(176) [sender=3.1.1]
rsync failed -- run git annex again to resume file transfer
failed
git-annex: copy: 1 failed
# End of transcript or log.
I think I've seen this where the shell was running some command at (non-interactive) login that output stuff and so screwed up the rsync protocol.
rsync with sufficient -vvvv will print out a lot of debugging info about the protocol.
It's weirder than that. I add a cow union mount over it, it works fine.
I copy the file, I drop the file, I remove the union mount. Again it's back in the broken state. Rebooting does not help, so it's not some very insistent lock.
Next I will try a copy of the repo, to see if that is able to carry over whatever strange state this thing is in.
Hm, not so sure that "rebooted, did not help" was actually true. I take that back.
Now I saw a stray
git-annex-shell recv-keyprocess mentioning that file. I killed it and now everything seems fine. I will keep this in mind for next time, to see if I can verify that this was actually the cause of the message, but maybe it's a clue.The stray recv-key is a good clue. git-annex-shell only allows one upload of a given file to run at a time. So if you get a transfer stalled out, it will reject another transfer attempt. This can sometimes happen when eg, migrating between networks and restarting an upload when the old one is still running on the server.
However, normally there is an error message "transfer already in progress".
It may be that your rsync is not forwarding that stderr through to display it, for some reason.
It would probably help if you can run the same git-annex shell command line on the server, verify that it fails with "transfer already in progress" when an recvkey of that key is already running. Then you could try sshing to the server noninteractively and having it run the same git-annex-shell command, and see if the error makes it through that.