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

borg appendonly config

Browse source
This commit is contained in:
Joey Hess 2020-12-28 16:23:38 -04:00
parent 0990d74574
commit b16e6fb4e6
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 35 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

41
doc/todo/allow_overriding_untrust_of_import_remotes.mdwn
View file

@ -18,38 +18,11 @@ 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
> There is Remote.appendonly, which prevents making import remotes
> untrusted. So if there were a way to set that for borg, it could
> be configured at initremote/enableremote time. But,
> Remote.Helper.ExportImport also assumes appendonly means that content can
> be accessed by Key, rather than by ImportLocation, which does not work
> for borg.
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.
>> [[done]] via Remote.untrustworthy --[[Joey]]