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.

I have not looked at borg 2 in any detail, but it seems they are trying to keep the CLI to some extent the same. So it seems it would depend on whether CLI changes break something git-annex relies on.

I'd treat any incompatability as a bug or todo on the git-annex side, so if you try it and find problems, please report them.

With borg 2.0 on the horizon, I was wondering how support for that would look should that be planned.

With how much has changed and the necessity to create new repos, it might make the most sense to create a separate borg2 remote, but I have now idea. Mostly just curious if there are any plans for that at all.

Turns out Remote.Directory did not need to add the size at all. I've fixed it.

Heyo,

Is it possible to assign multi-file torrent links to files, without needing to download the entire torrent again using Annex?

Consider the following scenario:

A multi-file torrent has been downloaded in the past, say, using qBittorrent...

... I then add the files to Git Annex, and would like to efficiently register torrent/magnet URLs for them...

Annex maps files to a multi-file torrent using #<n> suffixes, so I've tried the following:

1. aria2c --show-files <torrent file> -- to get the numbers for each file
2. git annex addurl --file "file.mp4" "magnet:...#<N>" -- to map the file to its original torrent/magnet

The following error occurs:

(downloading torrent file...) git-annex: That url contains multiple files according to the bittorrent remote; cannot add it to a single file.

If there's any information or clarification needed, please don't hesitate to let me know

$ git annex migrate --remove-size
migrate data.bin
git-annex: failed creating link from old to new key

That happens when the file is not present in the local repository. If you get the file first it will work.

Migrate needs the content present so it can populate the new key. Otherwise, there can be situation where the new key never ends up being populated with the content.