idea
This commit is contained in:
parent
0605cc1bfb
commit
afced1a8ba
1 changed files with 21 additions and 0 deletions
21
doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn
Normal file
21
doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn
Normal file
|
@ -0,0 +1,21 @@
|
|||
Currently, setting a repo to trusted can result in data loss if content
|
||||
gets removed from that repo. For this reason, --trust has been disabled,
|
||||
and `git-annex trust` needs --force.
|
||||
|
||||
My idea for a better way to handle this is to make trusted repos that
|
||||
cannot be checked not count toward satisfying mincopies. So while trusting
|
||||
a repository would let numcopies be violated still, it would avoid data
|
||||
loss. That would be enough to bring back --trust and not need --force.
|
||||
|
||||
Aside from preventing data loss in some situations, the impact of this
|
||||
behavior change would be that dropping content would fail in some
|
||||
situations where it used to work. Specifically, when a trusted repo
|
||||
contains content, but is not accessible, and no other accessible repo
|
||||
contains the content. That has been a valid use of trusted repos, but it's
|
||||
also obviously an unsafe one -- if that trusted repo has dropped the
|
||||
content in the meantime, it risks data loss.
|
||||
|
||||
So, is it worth breaking an existing, but unsafe use case, in order to make
|
||||
it easier to use trust safely?
|
||||
|
||||
--[[Joey]]
|
Loading…
Add table
Reference in a new issue