diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment
new file mode 100644
index 0000000000..f02fd2cd6c
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-16T17:10:24Z"
+ content="""
+"file content has changed" is a message from the directory special remote
+when it sees that a file in the directory has a different mtime,size,inode
+tuple (content identifier) than the one that was recorded when importing
+the tree.
+
+Maybe that has something to do with the duplicate files, since they would
+have different inodes. Except, it does try to support that; it can keep
+track of multiple content identifiers for a key, and when there are
+duplicate files, that works in my testing.
+
+I notice that, if I have a directory special remote that was initially
+set up with ignoreinodes=no, and I've imported a tree that way from it,
+I can cause what looks like this problem:
+
+	joey@darkstar:~/tmp/bench/x>git-annex enableremote t directory=../x ignoreinodes=yes
+	enableremote t ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/x>git-annex get 3 --from t
+	get 3 (from t...) 
+	  file content has changed
+
+Which seems like a bug that it allows changing it, but I think that the idea was
+that, after changing ignoreinores, the user would re-run git-annex import,
+which would re-import all the files since the content identifier has
+changed. Still, I think that 
+[[!commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7]] didn't consider that
+it could cause a get to fail.
+
+I know you have recently upgraded from a version that defaulted
+to ignoring inodes. Maybe you only need to re-run `git-annex import` from the
+directory remote to fix the problem?
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment
new file mode 100644
index 0000000000..03c7024b25
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-16T17:32:29Z"
+ content="""
+If I was on the wrong track with my first comment, it would be helpful
+to take a look at the content identifier that is recorded for
+the key, by running:
+
+	git show git-annex:$(git-annex examinekey SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4 --format='${hashdirlower}${key}.log.cid')
+
+The part after the UUID in the output is the content identifier(s). If more
+than one, they are separated by colons. The format of a content identifier
+is "inode size mtime", and the inode will be 0 if it was generated with
+ignoreinodes=yes. So you could then compare the content identifiers
+with the stat of the files in the directory special remote and see if
+something has actually changed.
+"""]]