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 ..

3 files changed, 61 insertions, 0 deletions

diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment
new file mode 100644
index 000000000..b580cdbe6
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-10T17:29:44Z"
+ content="""
+I recently fixed a bug that would
+likewise cause git-annex to fail on windows with a large file, although I
+didn't see it failing with this message.
+
+There's a good chance that git-annex version 5.20150205 might fix this
+problem. 
+
+I was able to successfully use git-annex with a 6 gb file, after the fixes.
+
+Please check, and followup. I'm closing this bug provisionally in the
+meantime.
+"""]]
diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment
new file mode 100644
index 000000000..0ea9dc4d1
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="bvaa"
+ subject="similar problem"
+ date="2016-03-01T08:12:27Z"
+ content="""
+I have a similar problem on Windows 7 64bit trying to add files that are around 5GB in size. I tried repository version 5 and 6 with same results.
+
+```
+$ git annex add bigfile
+add bigfile ok
+(recording state in git...)
+
+$ git annex status
+fatal: Cannot handle files this big
+```
+git-annex version: 6.20160229-g37a89cc
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV ConcurrentOutput TorrentParser Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 2 3 4 5
+
+"""]]
diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment
new file mode 100644
index 000000000..e6ad551e4
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-03-01T14:41:45Z"
+ content="""
+git (not git-annex) will throw this error if a file size is greater than
+`size_t`.
+
+This bug report seemed to originally concern git add being run on such a
+file, but I can't see how git-annex would do that, it doesn't add large
+files to git.
+
+I think that in the case of git-annex status, when it runs git status, that
+looks at work tree files, and so falls over if they're large, even if
+what's checked into git is a nice small git-annex symlink. This would also
+probably affect other places where git looks at worktree files, perhaps git
+diff (in v6 repo mode).
+
+Reopening bug report.
+"""]]