cleanup comments on removed news post

add news item for git-annex 10.20240731

releasing package git-annex version 10.20240731

analysis

very temporarily copy stack.yaml to stack-lts-18.13.yaml

Windows autobuilder is still using that and a vacation is blocking
updating it to use stack.yaml.

pinged

comment

[Bug] Trust but Verify: RClone

more fixes to build w/o servant

typo

update

todo

fix negative DATA when 1 node of a cluster has a partial transfer

avoid partial functions

This is horrible old code and ghc has started to warn about head and
tail. Rewrote it to avoid all partial functions except !! and guarded
uses of !! with length checks.

fix build without servant some more

comment

deindent

the indentation broke the arm64ancient build which edits the file

disable servant build flag for i386ancient

Its library stack is too old, and while lts-12.14 does include an old
version of servant, some libraries like http-client have been bumped up
from the lts to support eg http-client-restricted. So a newer servant
would be needed, which would lead to many more upgrades.

There might be a dependency set that works, but I have not been able to
find it so far. stack solver also failed to find one.

fix build without servant

update stack.yaml to nightly-2024-07-29 and remove stack-lts-18.13.yaml

Primarily because Windows needs a dependency bump to get stm-2.5.1
for Servant build flag.

This includes Win32-2.13.4.0 and aws-0.24 which adds some features
that windows had been missing out on as well.

Lots of warnings about head and tail will need to eventually be
addressed. Of course AFAIK the uses of it in git-annex are all safe.

fix syntax

temporarily disable servant build flag on windows

servant build flag needs stm-2.5.1

For writeTMVar. Would be possible to rewrite to use something else, but
I don't want to. Might be possible to write a writeTMVar that works with
the old version of stm.

fix build with text older than 2.0

enable servant in windows build

fix build with old text

Don't need decodeUtf8Lenient here because B64.encode surely always
generates utf8. So decodeUtf8 is safe, it will never throw an exception.

final fix to windows build

close

more fixes to windows build for content retention files

Will probably build successfully now. Still untested.

more fixes to windows build for content retention files

When proxying an upload to a special remote, verify the hash.

While usually uploading to a special remote does not verify the content,
the content in a repository is assumed to be valid, and there is no trust
boundary. But with a proxied special remote, there may be users who are
allowed to store objects, but are not really trusted.

Another way to look at this is it's the equivilant of git-annex-shell
checking the hash of received data, which it does (see StoreContent
implementation).

run with noMessages

This avoids extraneous output from p2phttp, including eg, progress
displays when transferring to proxied special remotes.

add libghc-servant-client-core-dev dep

changelog

update github badges

Seems the urls changed and the old ones will be falsely green forever.

Found new ones in readme at https://github.com/datalad/git-annex

add missing do on windows

comment

don't think I ever implementned the 422 idea, it will 404

wording

link

wording

typo

Merge branch 'httpproto'

Merge remote-tracking branch 'origin/httpproto'

update

preparing to merge

When proxying for a special remote, avoid unncessary hashing

Like the comment says, the client will do its own verification. But it was
calling verifyKeyContentPostRetrieval, which was hashing the file.

fix reversion in GET from proxy over http

4f3ae966662c38080fcafb9d5bbee4dedce566b8 caused a hang in GET,
which git-annex testremote could reliably cause.

The problem is that closing both P2P handles before waiting on the
asyncworker prevents all the DATA from getting sent.

The solution is to only close the P2P handles early when the
P2PConnection is being closed. When it's being released, let the
asyncworker finish. closeP2PConnection is called in GET when it was
unable to send all data, and in PUT when it did not receive all the
data, and in both cases closing the P2P handles early is ok.

p2phttp remotes are not readonly

That prevented testremote from working when remote.name.url = http://..

cleanly close proxy connection on interrupted PUT

An interrupted PUT to cluster that has a node that is a special remote
over http left open the connection to the cluster, so the next request
opens another one. So did an interrupted PUT directly to the proxied
special remote over http.

proxySpecialRemote was stuck waiting for all the DATA. Its connection
remained open so it kept waiting.

In servePut, checktooshort handles closing the P2P connection
when too short a data is received from PUT. But, checktooshort was only
called after the protoaction, which is what runs the proxy, which is
what was getting stuck. Modified it to run as a background thread,
which waits for the tooshortv to be written to, which gather always does
once it gets to the end of the data received from the http client.

That makes proxyConnection's releaseconn run once all data is received
from the http client. Made it close the connection handles before
waiting on the asyncworker thread. This lets proxySpecialRemote finish
processing any data from the handle, and then it will give up,
more or less cleanly, if it didn't receive enough data.

I say "more or less cleanly" because with both sides of the P2P
connection taken down, some protocol unhappyness results. Which can lead
to some ugly debug messages. But also can cause the asyncworker thread
to throw an exception. So made withP2PConnections not crash when it
receives an exception from releaseconn.

This did have a small change to the behavior of an interrupted PUT when
proxying to a regular remote. proxyConnection has a protoerrorhandler
that closes the proxy connection on a protocol error. But the proxy
connection is also closed by checktooshort when it closes the P2P
connection. Closing the same proxy connection twice is not a problem,
it just results in duplicated debug messages about it.

add debugging of opening and closing connections to proxies

idea

Added a comment: importtree=yes Support

remove unused imports

remove uuid from annex+http urls

Not needed it turns out.

set remote's annexUrl automatically

When the remote repository's git config file
has annex.url set to an annex+http url.

todo

documentation for p2phttp

avoid repeatedly parsing the proxy log

update

todo

fix hang in PUT of large file to a special remote node of a cluster over http

use closedv rather than separate endv

Doesn't fix any known problem, but this way if the connection does get
closed, it will notice.

remove temp file after upload to special remote

Merge remote-tracking branch 'origin/master' into httpproto

update

clean shut down of cluster connection when PUT is interrupted

An interrupted `git-annex copy --to` a cluster via the http server,
when repeated, failed. The http server output "transfer already in
progress, or unable to take transfer lock". Apparently a second
connection was opened to the cluster, because the first connection
never got shut down.

Turned out the problem was that when proxying to a cluster, it would read a
short ByteString from the client, and send that to the nodes. But that left the
nodes warning more. Meanwhile, the proxy was expecting a SUCCESS/FAILURE
message from the nodes. So it didn't return, and so the cluster connection
stayed open.

fix http proxying for a local git remote with a relative path

git-annex-shell expects an absolute path

found some bugs with clusters

clusters need enableInteractiveBranchAccess

As seen in commit 770aac97a75f64b86d73240055acffe1a5ed9f1a, a cluster
relies accurate location logs. If long-running processes are serving a
cluster, and one process puts a file, the other process needs to see
what nodes it was stored on when checking if the file is present.

smarter BranchState cache invalidation

Only invalidate a just-written file in the cache, not the whole cache.

This will avoid the possibly performance impact of cache invalidation
mentioned in commit 770aac97a75f64b86d73240055acffe1a5ed9f1a

share single BranchState amoung all threads

This fixes a problem when git-annex testremote is run against a cluster
accessed via the http server. Annex.Cluster uses the location log
to find nodes that contain a key when checking if the key is present or getting
it. Just after a key was stored to a cluster node, reading the location log
was not getting the UUID of that node.

Apparently the Annex action that wrote to the location log, and the one
that read from it were run with two different Annex states. The http server
does use several different Annex threads.

BranchState was part of the AnnexState, and so two threads could have
different BranchStates.

Moved BranchState to the AnnexRead, so all threads will see the common state.

This might possibly impact performance. If one thread is writing changes to the
branch, and another thread is reading from the branch, the writing thread will
now invalidate the BranchState's cache, which will cause the reading thread to
need to do extra work. But correctness is surely more important. If did is
found to have impacted performance, it could probably be dealt with by doing
smarter BranchState cache invalidation.

Another way this might impact performance is that the BranchState has a small
cache. If several threads were reading from the branch and relying on the value
they just read still being in the case, now a cache miss will be more likely.
Increasing the BranchState cache to the number of jobs might be a good
idea to amelorate that. But the cache is currently an innefficient list,
so making it large would need changes to the data types.

(Commit 4304f1b6aea19a5c402dc4f9d69aa4ff1c104c9b dealt with a follow-on
effect of the bug fixed here.)

better handling of content not available from cluster

Sending ERROR caused the client to get confused and protocol to freeze.
Better to send empty DATA and indicate it's not valid.

This fixes a hang in git-annex testremote of a cluster accessed via the
http server. That testremote is still failing, for some reason after
storing a test key, the cluster reports it as not present.

add --clusterjobs option and default to 1

The default of 1 is not ideal at all, but it avoids an accidental M*N
causing so much concurrency it becomes unusable.

cluster support in http API server

Wired it up and it seems to basically work, although the test suite is
not fully passing.

Note that --jobs currently gets multiplied by the number of nodes in the
cluster, which is probably not good.

remove duplicate code

tested shutdown of connection to http proxied special remote

I had worried it might not work properly, but it does, the endv works.

fix PUT to http proxied special remote

It was hanging because it never sent FAILURE in the INVALID case.
And putoffset always triggers the INVALID case.

thoughts on exporttree

update

UNLOCKCONTENT is not a top-level request

proxyRequest was treating UNLOCKCONTENT as a separate request.
That made it possible for there to be two different connections to the
proxied remote, with LOCKCONTENT being sent to one, and UNLOCKCONTENT
to the other one. A protocol error.

git-annex testremote now passes against a http proxied remote.

fix hang at end of PUT to proxied p2p http remote

sendExactly will now be sure to evaluate the whole lazy ByteString.

In this case, the lazy ByteString was exactly the right lenth.
But, it seems that L.take caused it to not actually be fully evaluated.

In servePut, this manifested as gather never being fully evaluated,
which caused the hang.

Very, very subtle, and horrible bug. Clearly the use of lazy ByteString
(or really just laziness) is at fault, and it would be very worth moving
to conduit or whatever to avoid this.

update

implement proxy connection pool

removeOldestProxyConnectionPool will be innefficient the larger the pool
is. A better data structure could be more efficient. Eg, make each value
in the pool include the timestamp of its oldest element, then the oldest
value can be found and modified, rather than rebuilding the whole Map.

But, for pools of a few hundred items, this should be fine. It's O(n*n log n)
or so.

Also, when more than 1 connection with the same pool key exists,
it's efficient even for larger pools, since removeOldestProxyConnectionPool
is not needed.

The default of 1 idle connection could perhaps be larger.. like the
number of jobs? Otoh, it seems good to ramp up and down the number of
connections, which does happen. With 1, there is at most one stale
connection, which might cause a request to fail.

initial report on keeping association with the remote

closeP2PConnection on interrupted GET

clean up after http p2p proxy GET is interrupted

There was an annex worker thread that did not get stopped.

It was stuck in ReceiveMessage from the P2PHandleTMVar.

Fixed by making P2PHandleTMVar closeable.

In serveGet, releaseP2PConnection has to come first, else the
annexworker may not shut down, if it's waiting to read from it.

In proxyConnection, call closeRemoteSide in order to wait for the ssh
process (for example).

close proxy remote side when done with it

oops

oops

clean up protocol version for proxying

The proxy always checks the protocol version of a remote before talking
to it in a version-specific way, so the protocol version in the ProxyParams
is the client's protocol version. The remote will always be at the same or
an older protocol version than the client.

Note that in relayDATAFinish, when the client is at protocol version 0,
the remote must thus be as well, and that's why its version is not
checked in the case for that.

With that clarified, it's evident that, in P2P.Http.State, there's no
need to look at the proxied remote's protocol version at all.

fix setting protocol version for v0 server

Before it was leaving the protocol version at the default, when it
was actually v0.

v0 has only ever been used over tor, which is probably why this bug was
never noticed.

fix hang in GET from http p2p proxy

serverP2PConnection = proxyfromclientconn causes serveGet to
signalFullyConsumedByteString to it, which is what it's waiting for

improve comment

update

http p2p proxy is now largely working

Added a comment

remove some debugging

wip

use a record to reduce the huge number of parameters