rename files containing :

This is mostly to let the repo check out on windows w/o using cygwin's git.

But, bash completion is also crap with : , so ..

5 files changed, 61 insertions, 0 deletions

diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
new file mode 100644
index 000000000..8379a7d82
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T19:12:37Z"
+ content="""
+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.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
new file mode 100644
index 000000000..268f36993
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 2"
+ date="2015-05-22T21:08:26Z"
+ content="""
+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.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
new file mode 100644
index 000000000..b2a335a0b
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 3"
+ date="2015-05-22T22:16:45Z"
+ content="""
+Note that a thousand files went over without a hitch, but this particular file consistently fails.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
new file mode 100644
index 000000000..cad761d14
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 4"
+ date="2015-05-24T17:41:17Z"
+ content="""
+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-key` process 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.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
new file mode 100644
index 000000000..85af7d221
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-05-26T14:52:11Z"
+ content="""
+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.
+"""]]