followup; open bug

doc/bugs/indeterminite_preferred_content_state_for_duplicated_file.mdwn

@@ -0,0 +1,15 @@
+Consider if file `foo` uses key K, and file `archive/bar` uses the same key K.
+Using standard client preferred content settings, `git annex drop --auto`
+will want to drop `archive/bar`, but `git annex get --auto` will want to get
+`foo`. `git annex sync --content` will do both operations, getting and then
+dropping the key. Running these commands repeatedly churns unncessarily.
+
+Fixing this needs a map from key to files using it. Then, when checking
+preferred content of `archive/bar`, it can see that `foo` also uses the
+key. Since `foo` is wanted, it should not drop the key, even though
+`archive/bar` is not wanted.
+
+Such a map exists, in the keys database, but only in v6 mode repositories.
+So, this seems solvable in v6 repositories, but not in v5.
+Also, the associated files map may not be accurate at all times, so that's
+a wrinkle to using it for this. --[[Joey]]

doc/design/caching_database.mdwn

@@ -3,6 +3,7 @@
 * [[bugs/incremental_fsck_should_not_use_sticky_bit]]
 * [[todo/wishlist:_pack_metadata_in_direct_mode]]
 * [[todo/cache_key_info]]
+* [[bugs/indeterminite_preferred_content_state_for_duplicated_file]]
 
 What do all these have in common? They could all be improved by
 using some kind of database to locally store the information in an
@@ -29,9 +30,11 @@ Store in the database the Ref of the branch that was used to construct it.
 2. Make sure that builds on all platforms, and works reliably. **done**
 3. Use sqlite db for associated files cache. **done** (only for v6 unlocked
    files)
-4. Also, use associated files db to construct views.
+4. Use associated files db when dropping files, to fix
-5. Use sqlite db for metadata cache.
+   [[bugs/indeterminite_preferred_content_state_for_duplicated_file]]
-6. Use sqlite db for list of keys present in local annex.
+5. Also, use associated files db to construct views.
+6. Use sqlite db for metadata cache.
+7. Use sqlite db for list of keys present in local annex.
 
 ## sqlite or not?
 

doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-19T18:53:04Z"
+ content="""
+Notice that the file it gets is empty, and the file it drops also appears
+to be an empty file, at least based on its filename. So, there is a single
+key used for both empty files.
+
+(There's also the two .aux files, which probably also have the same 8 byte
+content.)
+
+Your preferred content settings make one of the pair of files be wanted,
+and the other one not be wanted. In this situation, `get --auto` will get
+the key used for both files, and `drop --auto` will drop it. `sync
+--content` does both things, so repeatedly gets and then drops the key.
+
+One way to deal with this is to delete one of the copies of the file.
+Then it won't be in this mixed up state. But you may not want to do that.
+
+Another way to deal with it is to unlock one of the files, and add it back
+using `git annex add --backend=WORM $file`. This will make git-annex
+allocate a new key, only for that copy of the file.
+
+I do think this is a bug in git-annex, but not one that can immediately be
+fixed. I've opened a bug report at
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]].
+"""]]