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.

This bug only happens with the directory special remote and not others.

The problem is that the directory special remote implements importKey, and explicitly adds the size back! 15000dee07a06d04285351616915794bd6ec7f14 explains why it needs to do that.

Unfortunately it seems like I can't even remove the size after the import:

$ git switch --detach importdir/import
HEAD is now at 6d3aa43 import from importdir
$ git annex migrate --remove-size
migrate data.bin 
git-annex: failed creating link from old to new key
failed
migrate: 1 failed
[ble: exit 1]