diff options
author | 2016-07-19 15:04:41 -0400 | |
---|---|---|
committer | 2016-07-19 15:04:41 -0400 | |
commit | f61eccc54fecb7706e149da83e1f238e2b766436 (patch) | |
tree | 6c585bebb3f0f9bb932c60be8bf620225286c5a6 /doc | |
parent | 667f29402f00994174b3da88df8ad7eaf2cc4bed (diff) |
followup; open bug
Diffstat (limited to 'doc')
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]]. +"""]] |