2011-12-02 20:59:55 +00:00
|
|
|
Git-annex supports several levels of trust of a repository:
|
2011-01-26 18:09:06 +00:00
|
|
|
|
|
|
|
|
* semitrusted (default)
|
|
|
|
|
* untrusted
|
|
|
|
|
* trusted
|
2011-12-02 20:59:55 +00:00
|
|
|
* dead
|
2011-01-26 18:09:06 +00:00
|
|
|
|
2011-01-27 01:52:51 +00:00
|
|
|
## semitrusted
|
2011-01-26 18:09:06 +00:00
|
|
|
|
2010-12-28 21:17:02 +00:00
|
|
|
Normally, git-annex does not fully trust its stored [[location_tracking]]
|
|
|
|
|
information. When removing content, it will directly check
|
2010-12-29 21:01:56 +00:00
|
|
|
that other repositories have enough [[copies]].
|
2010-12-28 21:17:02 +00:00
|
|
|
|
|
|
|
|
Generally that explicit checking is a good idea. Consider that the current
|
2011-02-15 05:56:24 +00:00
|
|
|
[[location_tracking]] information for a remote may not yet have propagated
|
2010-12-28 21:17:02 +00:00
|
|
|
out. Or, a remote may have suffered a catastrophic loss of data, or itself
|
|
|
|
|
been lost.
|
|
|
|
|
|
2011-01-27 01:52:51 +00:00
|
|
|
There is still some trust involved here. A semitrusted repository is
|
2011-02-15 05:56:24 +00:00
|
|
|
depended on to retain a copy of the file content; possibly the only
|
2011-01-26 18:09:06 +00:00
|
|
|
[[copy|copies]].
|
|
|
|
|
|
2015-09-09 19:56:06 +00:00
|
|
|
(Being semitrusted is the default. The [[git-annex semitrust|git-annex-semitrust]] command
|
2011-06-01 21:49:37 +00:00
|
|
|
restores a repository to this default, when it has been overridden.
|
|
|
|
|
The `--semitrust` option can temporarily restore a repository to this
|
|
|
|
|
default.)
|
2011-01-26 18:09:06 +00:00
|
|
|
|
|
|
|
|
## untrusted
|
|
|
|
|
|
|
|
|
|
An untrusted repository is not trusted to retain data at all. Git-annex
|
2011-01-26 21:44:40 +00:00
|
|
|
will retain sufficient [[copies]] of data elsewhere.
|
2011-01-26 18:09:06 +00:00
|
|
|
|
|
|
|
|
This is a good choice for eg, portable drives that could get lost. Or,
|
|
|
|
|
if a disk is known to be dying, you can set it to untrusted and let
|
|
|
|
|
`git annex fsck` warn about data that needs to be copied off it.
|
|
|
|
|
|
2015-09-09 19:56:06 +00:00
|
|
|
To configure a repository as untrusted, use the [[git-annex untrust|git-annex-untrust]]
|
2011-01-26 18:09:06 +00:00
|
|
|
command.
|
|
|
|
|
|
|
|
|
|
## trusted
|
|
|
|
|
|
|
|
|
|
Sometimes, you may have reasons to fully trust the location tracking
|
|
|
|
|
information for a repository. For example, it may be an offline
|
2010-12-28 21:17:02 +00:00
|
|
|
archival drive, from which you rarely or never remove content. Deciding
|
|
|
|
|
when it makes sense to trust the tracking info is up to you.
|
|
|
|
|
|
2011-06-01 21:49:37 +00:00
|
|
|
To configure a repository as fully and permanently trusted,
|
2015-08-25 16:03:35 +00:00
|
|
|
use the [[git-annex-trust]] command.
|
2011-12-02 20:59:55 +00:00
|
|
|
|
2021-01-06 18:11:08 +00:00
|
|
|
Note that after dropping content from a trusted repo, other repos
|
|
|
|
|
that are out of sync and trust it to still contain the content
|
|
|
|
|
can drop copies, even though that will violate [[numcopies]]. So
|
|
|
|
|
using trusted repositories can lead to data loss. It is best to take
|
|
|
|
|
extreme care when dropping content from trusted repositories,
|
|
|
|
|
the same as if you were using `--force`.
|
|
|
|
|
|
2011-12-02 20:59:55 +00:00
|
|
|
## dead
|
|
|
|
|
|
|
|
|
|
This is used to indicate that you have no trust that the repository
|
|
|
|
|
exists at all. It's appropriate to use when a drive has been lost,
|
2015-04-17 14:42:16 +00:00
|
|
|
or a directory irretrievably deleted. It will make git-annex avoid
|
2011-12-02 20:59:55 +00:00
|
|
|
even showing the repository as a place where data might still reside.
|
2015-08-25 16:03:35 +00:00
|
|
|
|
|
|
|
|
To configure a repository as dead and lost, use the [[git-annex-dead]]
|
|
|
|
|
command.
|
