deal with git's CFLR nonsense once again

Work around git hash-object --stdin-paths's odd stripping of carriage
return from the end of the line (some windows infection), avoiding crashing
when the repo contains a filename ending in a carriage return.

CHANGELOG

@@ -1,3 +1,11 @@
+git-annex (10.20241203) UNRELEASED; urgency=medium
+
+  * Work around git hash-object --stdin-paths's odd stripping of carriage
+    return from the end of the line (some windows infection), avoiding
+    crashing when the repo contains a filename ending in a carriage return.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 02 Dec 2024 13:41:31 -0400
+
 git-annex (10.20241202) upstream; urgency=medium
 
   * add: Consistently treat files in a dotdir as dotfiles, even

Git/HashObject.hs

@@ -48,13 +48,17 @@ hashFile hdl@(HashObjectHandle h _ _) file = do
 	-- So, make the filename absolute, which will work now
 	-- and also if git's behavior later changes.
 	file' <- absPath file
-	if newline `S.elem` file'
+	if newline `S.elem` file' || carriagereturn `S.elem` file
 		then hashFile' hdl file
 		else CoProcess.query h (send file') receive
   where
 	send file' to = S8.hPutStrLn to file'
 	receive from = getSha "hash-object" $ S8.hGetLine from
 	newline = fromIntegral (ord '\n')
+	-- git strips carriage return from the end of a line, out of some
+	-- misplaced desire to support windows, so also use the newline
+	-- fallback for those.
+	carriagereturn = fromIntegral (ord '\r')
 
 {- Runs git hash-object once per call, rather than using a running
  - one, so is slower. But, is able to handle newlines in the filepath,

doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__.mdwn

@@ -73,3 +73,5 @@ It succeeds at moving the large `test2` file into `.git/annex/objects` and symli
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Yes! :) It's helped me manage an unruly mess of files, backups, and backups of backups.
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__/comment_1_0a3132101d9cc48afa55d467d1c3e12a._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-02T16:41:07Z"
+ content="""
+Reproduced on linux. This is pretty surprising since `\r` is not a
+particularly special character.
+
+Adding any file not matching largefiles with '\r` in its name will trigger
+it, the rest is not needed.
+
+`git hash-object --stdin-paths` is what is failing.
+
+	printf '/home/joey/tmp/tr/example/Icon3\r\n' | git hash-object --stdin-paths
+	fatal: could not open '/home/joey/tmp/tr/example/Icon3' for reading: No such file or directory
+
+So, this is a misbehavior in git, which prevents passing a filename ending
+in '\r' into --stdin-paths here. Probably git is removing DOS style CRLF
+when it should not. I have reported this (and several related bugs) to the
+git mailing list so it might get fixed.
+
+`git cat-file --batch` also has this behavior, and git-annex already works
+around it by treating "\r" the same as "\n" and avoiding using the batch
+interface for it. (It could use -z, which avoids the problem, but older
+git's don't support that option.)
+
+I've made git-annex treat "\r" as special for git hash-object as well.
+"""]]