summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2016-07-19 15:04:41 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2016-07-19 15:04:41 -0400
commitf61eccc54fecb7706e149da83e1f238e2b766436 (patch)
tree6c585bebb3f0f9bb932c60be8bf620225286c5a6 /doc
parent667f29402f00994174b3da88df8ad7eaf2cc4bed (diff)
followup; open bug
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/indeterminite_preferred_content_state_for_duplicated_file.mdwn15
-rw-r--r--doc/design/caching_database.mdwn9
-rw-r--r--doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment28
3 files changed, 49 insertions, 3 deletions
diff --git a/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file.mdwn b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file.mdwn
new file mode 100644
index 000000000..4f516a61c
--- /dev/null
+++ b/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]]
diff --git a/doc/design/caching_database.mdwn b/doc/design/caching_database.mdwn
index fe5d565fd..87efd9810 100644
--- a/doc/design/caching_database.mdwn
+++ b/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.
-5. Use sqlite db for metadata cache.
-6. Use sqlite db for list of keys present in local annex.
+4. Use associated files db when dropping files, to fix
+ [[bugs/indeterminite_preferred_content_state_for_duplicated_file]]
+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?
diff --git a/doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment b/doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment
new file mode 100644
index 000000000..f4beaf50c
--- /dev/null
+++ b/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]].
+"""]]