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 ..
This commit is contained in:
Joey Hess 2016-03-12 12:57:18 -04:00
parent b02f813ed8
commit 7125a1fb27
Failed to extract signature
781 changed files with 0 additions and 0 deletions

View file

@ -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.
"""]]

View file

@ -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.
"""]]

View file

@ -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.
"""]]

View file

@ -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.
"""]]

View file

@ -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.
"""]]