document annex.thin risk to locked files pointing at same content

doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn

@@ -7,3 +7,8 @@ Also, with `annex.thin`, the [[invariant|internals]] that `.git/annex/objects/aa
 [[`git-annex-drop`|git-annex-drop]] succeeds but does not actually drop the file.
 
 Also, even if the current repo is trusted, with `annex.thin`, an unlocked file should not count as a trusted copy.
+
+[[!tag confirmed]]
+
+> documentation updated to mention this unfixable wart. Ugh. [[done]]
+> --[[Joey]]

doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment

@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-21T19:28:52Z"
+ content="""
+Confirmed this is still a problem. `git-annex fsck` does detect and deal
+with it, by eg deleting the corrupted object.
+
+It seems like it would be hard for git-annex to make other files that use
+the same object be unlocked. Consider a repo with one file, that is
+unlocked and uses an object. Then a `git merge` adds another, locked file,
+using the same object. git-annex didn't have a chance to run at all, and
+now the stage is set for this problem to happen if the user appends to the
+unlocked file.
+
+In a way, the docs for annex.thin do warn the user about this. If you squint
+just right:
+
+	... but when a modification is made to a
+        file, you will lose the local (and possibly only)  copy  of  the
+        old version
+
+But, git-annex goes out of its way to avoid 2 unlocked files being hardlinked
+when using annex.thin. So it seems wrong that a locked file and an unlocked file
+will be hard linked, and that the locked file can get corrupted.
+
+Ok, I've made the docs warn about it, and I think that is just the best that
+can be done. The only real fix would be to remove annex.thin.
+"""]]