let Remote.availability return Unavilable
This is groundwork for making special remotes like borg be skipped by sync when on an offline drive. Added AVAILABILITY UNAVAILABLE reponse and the UNAVAILABLERESPONSE extension to the external special remote protocol. The extension is needed because old git-annex, if it sees that response, will display a warning message. (It does continue as if the remote is globally available, which is acceptable, and the warning is only displayed at initremote due to remote.name.annex-availability caching, but still it seemed best to make this a protocol extension.) The remote.name.annex-availability git config is no longer used any more, and is documented as such. It was only used by external special remotes to cache the availability, to avoid needing to start the external process every time. Now that availability is queried as an Annex action, the external is only started by sync (and the assistant), when they actually check availability. Sponsored-by: Nicholas Golder-Manning on Patreon
This commit is contained in:
parent
7f7c95b771
commit
9286769d2c
28 changed files with 86 additions and 65 deletions
|
@ -45,7 +45,7 @@ Recent versions of git-annex respond with a message indicating
|
|||
protocol extensions that it supports. Older versions of
|
||||
git-annex do not send this message.
|
||||
|
||||
EXTENSIONS INFO ASYNC GETGITREMOTENAME
|
||||
EXTENSIONS INFO ASYNC GETGITREMOTENAME UNAVAILABLERESPONSE
|
||||
|
||||
The special remote can respond to that with its own EXTENSIONS message, listing
|
||||
any extensions it wants to use.
|
||||
|
@ -207,9 +207,19 @@ the special remote can reply with `UNSUPPORTED-REQUEST`.
|
|||
(Ie stored in the cloud vs on a local disk.)
|
||||
If the remote replies with `UNSUPPORTED-REQUEST`, its availability
|
||||
is assumed to be global. So, only remotes that are only reachable
|
||||
locally need to worry about implementing this.
|
||||
locally need to worry about implementing this.
|
||||
This is queried at remote startup, so should avoid doing anything that
|
||||
can take long to run or is expensive. Checking if a directory where the
|
||||
remote stores files is currently mounted is the kind of thing it makes
|
||||
sense to do here.
|
||||
* `AVAILABILITY GLOBAL|LOCAL`
|
||||
Indicates if the remote is globally or only locally available.
|
||||
* `AVAILABILITY UNAVAILABLE`
|
||||
Indicates that the remote is not currently available.
|
||||
This will prevent some git-annex commands like `git-annex sync` from
|
||||
trying to use the remote.
|
||||
Older versions of git-annex do not support this response, so avoid
|
||||
sending it unless the `UNAVAILABLERESPONSE` extension is enabled.
|
||||
* `CLAIMURL Url`
|
||||
Asks the remote if it wishes to claim responsibility for downloading
|
||||
an url.
|
||||
|
@ -445,13 +455,16 @@ avoid talking to the buggy old version of git-annex.
|
|||
These protocol extensions are currently supported.
|
||||
|
||||
* `INFO`
|
||||
This makes the `INFO` message available to use.
|
||||
This allows using the `INFO` message.
|
||||
* `ASYNC`
|
||||
This lets multiple actions be performed at the same time by
|
||||
a single external special remote program, rather than starting multiple
|
||||
programs. See the [[async_appendix]] for details.
|
||||
* `GETGITREMOTENAME`
|
||||
This makes the `GETGITREMOTENAME` message available to use.
|
||||
This allows using the `GETGITREMOTENAME` message.
|
||||
* `UNAVAILABLERESPONSE`
|
||||
This allows the `AVAILABILITY UNAVAILABLE` response to be used
|
||||
in reply to `GETAVAILABILITY`.
|
||||
|
||||
## signals
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue