datalad_next.annexbackends.xdlra
git-annex external backend XDLRA for git-remote-datalad-annex
- class datalad_next.annexbackends.xdlra.DataladRepoAnnexBackend(annex)[source]
Bases:
Backend
Implementation of an external git-annex backend
This backend is tightly coupled to the git-remote-datalad-annex and hardly of any general utility. It is essentially aiming to be the leanest possible implementation to get git-annex to transport the content of two distinct files to and from a special remote. This backend is unlike most backends, because there is no fixed association of a particular file content to a particular key. In other words, the key content is expected to change without any change in the key name.
Only two keys are supported:
XDLRA--refs
XDLRA--repo-export
XDLRA--refs
contains a "refs" list of a Git repository, similar to the output ofgit for-each-ref
.XDLRA--repo-export
hold a ZIP archive of a bare Git repository.- can_verify()[source]
Returns whether the backend can verify the content of files match a key it generated. The verification does not need to be cryptographically secure, but should catch data corruption.
- Return type:
bool
- gen_key(local_file)[source]
Examine the content of local_file and from it generate a key.
While it is doing this, it can send any number of PROGRESS messages indication the position in the file that it's gotten to.
- Parameters:
local_file (str) -- Path for which to generate a key. Note that in some cases, local_file may contain whitespace.
- Returns:
The generated key.
- Return type:
str
- Raises:
BackendError -- If the file could not be received from the backend.
- is_cryptographically_secure()[source]
Returns whether keys it generates are verified using a cryptographically secure hash.
Note that sha1 is not a cryptographically secure hash any longer. A program can change its answer to this question as the state of the art advances, and should aim to stay ahead of the state of the art by a reasonable amount of time.
- Return type:
bool
- is_stable()[source]
Returns whether a key it has generated will always have the same content. The answer to this is almost always yes; URL keys are an example of a type of key that may have different content at different times.
- Return type:
bool
- verify_content(key, content_file)[source]
Examine a file and verify it has the content expected given a key
While it is doing this, it can send any number of PROGRESS messages indicating the position in the file that it's gotten to.
If can_verify() == False, git-annex not ask to do this.
- Return type:
bool