added retrieveKeyFileInOrder and ORDERED to external special remote protocol

I anticipate lots of external special remote programs will neglect
implementing this. Still, it's the right thing to do to assume that some
of them may write files out of order. Probably most external special
remotes will not be used with a proxy. When someone is using one with a
proxy, they can always get it fixed to send ORDERED.
This commit is contained in:
Joey Hess 2024-10-15 15:35:09 -04:00
parent f920d90781
commit d9b4bf4224
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
28 changed files with 80 additions and 13 deletions

View file

@ -55,8 +55,8 @@ any extensions it wants to use.
Next, git-annex will generally send a message telling the special
remote to start up. (Or it might send an INITREMOTE or EXPORTSUPPORTED or
LISTCONFIGS, or perhaps other things in the future, so don't hardcode this
order.)
LISTCONFIGS, or perhaps other things in the future, so don't
hardcode this order.)
PREPARE
@ -118,7 +118,7 @@ The following requests *must* all be supported by the special remote.
* `PREPARE`
Tells the remote that it's time to prepare itself to be used.
Only a few requests for details about the remote can come before this
(EXTENSIONS, INITREMOTE, EXPORTSUPPORTED, and LISTCONFIGS,
(EXTENSIONS, INITREMOTE, EXPORTSUPPORTED and LISTCONFIGS,
but others may be added later).
* `PREPARE-SUCCESS`
Sent as a response to PREPARE once the special remote is ready for use.
@ -203,6 +203,15 @@ the special remote can reply with `UNSUPPORTED-REQUEST`.
(See Config/Cost.hs for some standard costs.)
* `COST Int`
Indicates the cost of the remote.
* `GETORDERED`
Asks the remote if it will always write files in order when performing a
`TRANSFER RETRIEVE`. Writing in order lets a proxy stream content from
the remote. When this is not implemented, git-annex assumes the
remote may write parts of the file out of order.
* `ORDERED`
Indicates that files are written in order.
* `UNORDERED`
Indicates that files are not written in order.
* `GETAVAILABILITY`
Asks the remote if it is locally or globally available.
(Ie stored in the cloud vs on a local disk.)
@ -221,6 +230,8 @@ the special remote can reply with `UNSUPPORTED-REQUEST`.
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.
* `ORDERED`
* `CLAIMURL Url`
Asks the remote if it wishes to claim responsibility for downloading
an url.

View file

@ -364,10 +364,6 @@ remote to the usual temp object file on the proxy, but without moving that
to the annex object file at the end. As the temp object file grows, stream
the content out via the proxy.
> This needs the same process to read and write the same file, which is
> disallowed in Haskell (without going lowlevel in a way that seems
> difficult).
Some special remotes will overwrite or truncate an existing temp object
file when starting a download. So the proxy should wait until the file is
growing to start streaming it.