comment

doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_1_823458893eb87f1331da050d68486209._comment

@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-12T17:38:43Z"
+ content="""
+git-annex doesn't mess with filename encodings except for the new escaping
+on output. But as far as the path from podcast to disk, it's bytes in and
+bytes out with no concern for encoding. So I don't know how you got these
+two files, but it seems a reasonable hypotehesis that the podcast changed
+the title encoding (and perhaps then changed it back).
+
+It's strange to me that you don't have two separate files visible on disk.
+These are different filenames after all. I wonder if you are using a filesystem
+or OS that treats those as the same filename. That would certianly make
+it harder to list the files some other way and choose one to paste to `git rm`.
+
+Note that git has the same problem of many commands not accepting filenames
+output by other commands.
+
+	joey@darkstar:~/tmp/demo>touch foö
+	joey@darkstar:~/tmp/demo>git add foö
+	joey@darkstar:~/tmp/demo>git status
+	On branch master
+
+	No commits yet
+	
+	Changes to be committed:
+	  (use "git rm --cached <file>..." to unstage)
+		new file:   "fo\303\266"
+	joey@darkstar:~/tmp/demo>git rm --cached "fo\303\266"
+	fatal: pathspec 'fo\303\266' did not match any files
+
+The best workaround I know of is to use `git -c core.quotePath=false`
+to get it to output the actual filenames.
+
+I do think it might be worth adding an option to git-annex to make it 
+accept the quotepath formatted filenames. I don't think it can by default.
+"""]]