mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

let Remote.availability return Unavilable

Browse source 
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:
Joey Hess 2023-08-16 14:31:31 -04:00
parent 7f7c95b771
commit 9286769d2c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
28 changed files with 86 additions and 65 deletions
Download patch file Download diff file Expand all files Collapse all files

21
doc/design/external_special_remote_protocol.mdwn
View file

@ -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