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 of git 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

datalad_next.annexbackends.xdlra.main()[source]

Entry point for the backend utility