[[!comment format=mdwn
 username="joey"
 subject="""comment 3"""
 date="2019-03-18T18:16:53Z"
 content="""
annex.thin does allow data loss to happen, and just because there's
another annex link in the repository that points at the same object
file does not mean data loss is not acceptable.

While it might seem that, when adding the file with dup content, git-annex
could notice that the object file has been modified, and so replace it with
the new copy from ffoo, that would leave the same problem in 
this equivilant situation:

        # echo hi > 1
        # echo hi > 2
        # git annex add 1 2
        # git annex unlock 1
        # echo bye > 1
        # cat 2
        bye

The surprising thing to me is that `git annex fsck 2` (or ffoo in your
example) doesn't find any problem with it, despite it pointing at a
changed object file that doesn't have the right hash.

Fsck doesn't want to complain about *expected* data loss when an unlocked
file has been modified and annex.thin caused the old version to be lost.
But, when fscking an annex symlink, that shouldn't apply.
"""]]
