mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

todo

Browse source
This commit is contained in:
Joey Hess 2020-12-22 15:01:07 -04:00
parent 82e43da936
commit f31bdd0b19
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 39 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

36
doc/special_remotes/borg.mdwn
View file

@ -30,39 +30,3 @@ remote:
# git annex initremote borg type=borg borgrepo=/path/to/borgrepo scan=`pwd` # git annex initremote borg type=borg borgrepo=/path/to/borgrepo scan=`pwd`
# borg create /path/to/borgrepo `pwd`::{now} # borg create /path/to/borgrepo `pwd`::{now}
# git annex sync borg # git annex sync borg
## trust levels, borg delete and borg prune
git-annex will by default treat the borg special remote as untrusted, so
will not trust it to continue to contain a [[copy|copies]] of any annexed
file. This is necessary because you could run `borg delete` or `borg prune`
and remove the copy from the borg repository. If you choose to set the
trust level of the borg repository to a higher level, you need to avoid
using such commands with that borg repository.
Consider this example:
git-annex add annexedfile
borg create /path/to/borgrepo `pwd`::foo
git-annex sync borg
git-annex semitrust borg
git-annex drop annexedfile
Now the only copy of annexedfile is in the borg repository.
borg create /path/to/borgrepo `pwd`::bar
borg delete /path/to/borgrepo::foo
git-annex sync borg
git-annex whereis annexedfile
Now no copies of annexfile remain, because the "foo" archive
in the borg repository was the only one to contain it, and it was deleted.
So either keep the borg special remote as untrusted, and use such borg
commands to delete old archives as needed, or avoid using `borg delete`
and `borg prune`, and then the remote can safely be made semitrusted or
trusted.
Also, if you do choose to delete old archives, make sure to never reuse
that archive name for a new archive. git-annex may think it's the same
archive it saw before, and not notice the change.

39
doc/todo/allow_overriding_untrust_of_import_remotes.mdwn
View file

@ -14,3 +14,42 @@ Currently:
The borg special remote is one example of one where it's easy for the user to The borg special remote is one example of one where it's easy for the user to
decide they're going to not delete old archives from it, and so want git-annex decide they're going to not delete old archives from it, and so want git-annex
to trust it. to trust it.
Below is some docs I wrote for the borg special remote page, should be
moved there when this gets fixed. --[[Joey]]
## trust levels, borg delete and borg prune
git-annex will by default treat the borg special remote as untrusted, so
will not trust it to continue to contain a [[copy|copies]] of any annexed
file. This is necessary because you could run `borg delete` or `borg prune`
and remove the copy from the borg repository. If you choose to set the
trust level of the borg repository to a higher level, you need to avoid
using such commands with that borg repository.
Consider this example:
git-annex add annexedfile
borg create /path/to/borgrepo `pwd`::foo
git-annex sync borg
git-annex semitrust borg
git-annex drop annexedfile
Now the only copy of annexedfile is in the borg repository.
borg create /path/to/borgrepo `pwd`::bar
borg delete /path/to/borgrepo::foo
git-annex sync borg
git-annex whereis annexedfile
Now no copies of annexfile remain, because the "foo" archive
in the borg repository was the only one to contain it, and it was deleted.
So either keep the borg special remote as untrusted, and use such borg
commands to delete old archives as needed, or avoid using `borg delete`
and `borg prune`, and then the remote can safely be made semitrusted or
trusted.
Also, if you do choose to delete old archives, make sure to never reuse
that archive name for a new archive. git-annex may think it's the same
archive it saw before, and not notice the change.