comment

doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_5_68a3936700a02a17d0379d96880eea15._comment

@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-20T16:23:07Z"
+ content="""
+The two files have the same two inodes that are recorded in the git-annex
+branch. The size and mtime also seem to match. Interesting,
+it must be another problem than the one I fixed.
+
+I wonder if it's expecting the first file to have the second one's inode,
+or vice-versa?
+
+I don't know how that would have happened to you, but I was able to force
+it to happen, by importing a tree from a directory remote that had 2
+duplicate files. Then I swapped the names of the 2 files in the directory.
+This causes git-annex get to fail with the same error message.
+
+That must be a bug itself, because re-importing from the special remote
+generates the same tree (of course) and so get continues failing, there is
+no recovery possible except deleting or touching the files.
+
+Aha: Another indication that handling of duplicate imported files is broken
+is to import two files, and then delete the first of them. This also causes
+git-annex get to fail, but now it always fails with "no such file or
+directory". It is only trying to get the first file, it does not try the
+second. Re-importing from the special remote teaches it about the deleted
+file, and that leads back to the "file content has changed" problem because
+it seems to be looking for the deleted file's inode. So that's one way you
+could have gotten into this situation without the unlikely swapping of two
+duplicate files.
+"""]]