62 lines
2.9 KiB
Text
62 lines
2.9 KiB
Text
|
[[!comment format=mdwn
|
||
|
|
username="joey"
|
||
|
|
subject="""comment 1"""
|
||
|
|
date="2019-06-26T14:54:01Z"
|
||
|
|
content="""
|
||
|
|
The main operations on keys are:
|
||
|
|
|
||
|
|
* generate
|
||
|
|
* verify
|
||
|
|
* is stable (always refers to the same data, used only to determine if
|
||
|
|
chunks can be used when storing the content on a special remote)
|
||
|
|
* is verifiable with a hash (for annex.security.allow-unverified-downloads)
|
||
|
|
* is cryptographically secure hash
|
||
|
|
|
||
|
|
Note that the last two of those are not currently part of the Backend
|
||
|
|
object but would need to be moved to it to implement external backends.
|
||
|
|
|
||
|
|
Now, if a external backend is not installed or is broken, how would those
|
||
|
|
operations failing be handled?
|
||
|
|
|
||
|
|
* generate: Not a problem, git-annex already falls back to another backend
|
||
|
|
if a backend fails to generate a key.
|
||
|
|
* verify: This would need to return False. Since verification
|
||
|
|
is done after download in the default configuration, this would make
|
||
|
|
the downloaded content be thrown away. Seems likely it would result in
|
||
|
|
repeated downloads of the same content when git-annex is run
|
||
|
|
repeatedly, or when using the assistant.
|
||
|
|
fsck and reinject would also fail, so if a repo contained content using
|
||
|
|
an external backend and the program broken, fsck could move all the
|
||
|
|
content to .git/annex/bad/
|
||
|
|
* is verifiable with a hash: Affects downloads same as verify.
|
||
|
|
* is cryptographically secure hash: Similar to verify, but also affects
|
||
|
|
uploads when annex.securehashesonly is set.
|
||
|
|
|
||
|
|
So I think that all these operations except for generate would need to have
|
||
|
|
their type changed from Bool to Maybe Bool, and all code that uses them
|
||
|
|
handle the case where the operation was unable to be performed.
|
||
|
|
|
||
|
|
For fsck, it might need to start checking files it had previously moved to
|
||
|
|
bad, and move them back into the annex if they now verify due to the
|
||
|
|
external backend having gotten fixed.
|
||
|
|
|
||
|
|
For downloads, if it can't verify, it might move to some holding location,
|
||
|
|
and avoid re-downloading objects that are already located there. This would
|
||
|
|
add more problems though; what if all the objects in that holding location
|
||
|
|
use too much disk space? Should drop also drop them?
|
||
|
|
|
||
|
|
Or the external backend could be tested somehow before starting a download
|
||
|
|
(or a fsck) and skip its key if it's not installed or broken. But such a test
|
||
|
|
can't catch every possible breakage. It's hard to see how such a test
|
||
|
|
can do more than checking that it can start the program and that the
|
||
|
|
program seems to be speaking the right protocol version.
|
||
|
|
|
||
|
|
I suppose we could say that, if a external backend works to that extent but
|
||
|
|
then breaks, the resulting bad behavior is its fault and not really the
|
||
|
|
concern of git-annex. Or I could rationalize, that an external special
|
||
|
|
remote can break in ways that eg, prevent content being moved to it, so it
|
||
|
|
piles up in the local repo and uses too much disk space, and that this new
|
||
|
|
potential breakage is not much worse -- though it seems the scenarios where
|
||
|
|
it would have an adverse affect are likely to be more common.
|
||
|
|
"""]]
|