reopen on second thought

doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn

@@ -9,6 +9,3 @@ Also, with `annex.thin`, the [[invariant|internals]] that `.git/annex/objects/aa
 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

@@ -24,6 +24,5 @@ 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.
+I've made the docs warn about it better.
 """]]

doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_2_a6806787dc0163f67dc141415c951add._comment

@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-22T17:45:08Z"
+ content="""
+Ugh, I had closed this as not solvable, but on second thought, it's a very
+real wart and if it's not solvable that doesn't make it not a problem.
+
+And it does seem that it could be solved in some outside the box way. 
+
+For example, what if thin files were not hard links to the object file?
+Now, they *have* to hard link to somewhere, to prevent git checkout from
+deleting the only copy of a thin file. But it could hard link to a
+different name in the object directory. One that symlinks do not point to.
+
+Then `git-annex fix` or fsck would need to notice when a symlink points to
+an object file that is missing, and copy the thin file to it to populate
+it. And, something might also want to reap object files that have become
+only used by thin files.
+"""]]