well -- head also stalls

smaug:/tmp/ds000113
$> git annex list | head
here
|origin
||s3-PRIVATE
|||s3-PUBLIC
||||web
|||||bittorrent
||||||
___X__ derivatives/linear_anatomical_alignment/sub-01/ses-forrestgump/func/sub-01_ses-forrestgump_task-forrestgump_rec-XFMdico7Tad2grpbold7Tad_run-01_bold.mat
___X__ derivatives/linear_anatomical_alignment/sub-01/ses-forrestgump/func/sub-01_ses-forrestgump_task-forrestgump_rec-XFMdico7Tad2grpbold7Tad_run-02_bold.mat
___X__ derivatives/linear_anatomical_alignment/sub-01/ses-forrestgump/func/sub-01_ses-forrestgump_task-forrestgump_rec-XFMdico7Tad2grpbold7Tad_run-03_bold.mat

workaround

*$> head -n1 <(git-annex find --not --in here --fast)
derivatives/linear_anatomical_alignment/sub-01/ses-forrestgump/func/sub-01_ses-forrestgump_task-forrestgump_rec-XFMdico7Tad2grpbold7Tad_run-01_bold.mat

I have started a disableremote branch that adds a git-annex disableremote command. That same command will be able to be used for ephemeral=yes.

As it stands, the command works, but there is some information about the remote that it does not remove. I think for this purpose, it needs to at least remove the config uuid of the sameas remote from the private remote.log journal file. Otherwise that file will grow by one line each time an ephemeral delegate is used.

Removing cached annex creds, etc would also be good, but is not essential; they would get overwritten on next use. And, since cached creds use a filename based on the uuid, there's actually no way to know if a cached creds is for an delegate or are creds used by the external special remote with the same uuid. This actually seems like a bit of a bug with --sameas in general, that if two sameas remotes both use cached creds, they will clash. (Perhaps creds should use the config-uuid.)

because noone has requested it

I came to this while considering using git-annex to importtree from rclone.

The use case could be automation of workflow to work with docs on google drive or alike (docflow) or even more so for the con/serve "concept" since people do keep and collaborate via google drives and dropboxes. I do not have (yet) a clear idea on for which funded project this could apply, but it might become relevant/affordable one way or another if we guestimate the amount of work needed. Also the protocol enhancement for import/export-tree already looks quite thought-through.

The delegate branch now has the exension working. As it stands, I left out the ephemeral=yes|no, so the delegate remote remains in the git config and elsewhere after git-annex stops running, and will be reused next time it's needed.

I suspect that it might not matter that delegate remotes are not ephemeral. Their config does not get written to the git-annex branch and their configuration prevents the user from accidentially using them. The traces that hit the disk are just an implementation detail which can easily be ignored.

So I'm inclined to merge the branch as it stands. But that would mean that, if ephemeral support is later added it would need to be a new extension eg "DELEGATE-EPHEMERAL".

Coming back to this one, turns out this is feasible using git annex registerurl:

aria2c --show-files multi-file.torrent
# get the number of the file
git annex registerurl "$(git annex lookupkey file.mp4)" "magnet:...#<number>"

Works as intended; however, this will skip verification, so it's imperative that this is only used when you are 100% certain the file in the torrent is exactly the same your local one.

Note that forgejo does support raw file access, and I expect that it supports range requests for annex objects.

The p2phttp endpoint where it might make sense to support range requests is /git-annex/$uuid/key/$key

When p2phttp is proxying to a special remote, it would need to download the whole file from the special remote even if the range request was for a small part. So I don't think it should be supported for proxying.

One way to implement this might be to use Servant.Server.StaticFiles with a StaticSettings ssLookupFiles that returns the file location under .git/annex/objects/ (or even a location in another git-annex repository when proxying to one, eg a cluster node.) That uses warp's built-in static file serving, which supports range requests.

But how to handle authentication? It seems like the only way would be to reimplement p2phttp's authentication checking as WAI middleware.