A race condition caused a small fraction of requests to hang with the
object mostly transferred. Or, in some cases, STM deadlock messages to
be displayed without a hang.
See comments for analysis. I don't entirely understand what is going on
with all the filling of endv, but this clearly fixes the race.
The same way git does.
Affected repository types are regular git ssh remotes, and also gcrypt
remotes, and potentially also bup remotes.
repoPath is used for such repositories accessed over ssh. uriPath is used
in some other places, eg the bittorrent special remote, where it would not
be appropriate to mimic git's behavior. The distinction seems to hold up
well from what I can see.
The ordering of uriFragment after uriQuery is to correctly handle cases
where both appear in an url. "ssh://localhost/tmp/foo?baz#bar" has an
uriFragment of "#bar" and an uriQuery of "?baz". On the other hand,
"ssh://localhost/tmp/foo#baz?bar" has an uriFragment of "#baz?bar" and no
uriQuery.
Sponsored-by: Dartmouth College's DANDI project
As a feature only supported by the webapp, and not by git-annex at the
command line, this is by now a very obscure corner of git-annex, and not
one I want to keep maintaining.
It's worth removing it to avoid the security expsure alone. People using
the assistant w/o the webapp probably don't expect it to be listening on
a UDP port for a handrolled protocol, but it was.
The webapp has supported pairing via magic-wormhole since 2016, which
makes a link including between local computers, albeit with the overhead
of tor. That sort of covers the same use case. Of course advanced users
can easily enough add a ssh remote to their repository themselves, using
a hostname on the local network.
Sponsored-by: unqueued
Fix bug that made changes to a special remote sometimes be missed when
importing a tree from it. The diff import would miss when a change was
exported, then manually undone on the special remote (eg deleting a newly
exported file). A full import is needed to catch such changes.
After upgrading, any such missed changes will be included in the next
tree imported from a special remote. This happens because the previously
recorded content identifier tree does not have export information included,
so it is treated as invalid, and a full import is done.
Fixes reversion introduced in version 10.20230626, commit
40017089f2
Unfortunately, this does mean that after each export, the next import will
be a full import. Which can take significantly longer than the diff import
does, when there are a lot of files in the tree.
It would be better if exporting also update the content identifier tree.
However, I don't know if that can be done inexpensively. It would be future
optimisation work, in any case.
(That could only be done for an export that is run in the same
repository as the import. When an export is run in a different repository,
the export.log gets updated, and that propagates to the repository where
import is later run. At that point, a full import is done.)
Sponsored-by: Luke T. Shumaker
