complications

doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_10_f57e3d77a0ee6a504fa9cb404ab7a681._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-05-21T18:14:18Z"
+ content="""
+There must also be the same problem for required content, and that should
+also be fixed. Will be easy to do once the information is gathered
+into the keys database.
+"""]]

doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_9_49966d7fcd70a6ff40e4de61f96b3b83._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-05-21T17:53:21Z"
+ content="""
+There is overlap in the above plan with Database.Keys.reconcileStaged.
+That already stats the index, and updates associated files for changes
+made in the index. It does not handle locked files, and it only diffs
+from the index to HEAD, so when git checkout is used, it does not
+see those changes. (git runs the git-annex clean filter for those,
+and that updates the associated files database, but that also only handles
+unlocked files, not locked files).
+
+reconcileStaged is run every time the keys db is opened,
+so it runs perhaps more frequently than is needed for this. Although it
+does not run in every command, or even most commands. Eg, find and whereis
+do not use the keys db. It might be acceptable performance to do the
+additional work there.
+
+Also, handleDropsFrom queries the keys database for associated files
+already, and actually already checks if the key is preferred content of
+other files. So `git-annex sync --content`, which uses that, already
+avoids the problem for unlocked files, but not for locked files.
+`git annex drop` does not use that.
+"""]]