avoid trying to export tree to proxied exporttree=yes remotes

This avoids a lot of ugly messages when syncing with such a remote.
The export tree happens on the proxy side.

updateproxy, updatecluster check annexobjects=yes

updateproxy, updatecluster: Prevent using an exporttree=yes special remote
that does not have annexobjects=yes, since it will not work.

update

Merge branch 'master' into exportreeplus

catch ClientError from withClientM

When getting from a P2P HTTP remote, prompt for credentials when required,
instead of failing.

This feels like it might be a bug in servant-client. withClientM's type
suggests it would not throw a ClientError. But it does in this case.

comment

proxy stores received keys to known export locations

This handles the workflow where the branch is first pushed to the proxy,
and then files in the exported tree are later are copied to the proxied remote.

Turns out that the way the export log is structured, nothing needs
to be done to finalize the export once the last key is sent to it. Which
is great because that would have been a lot of complication. On
receiving the push, Command.Export runs and calls recordExportBeginning,
does as much as it can to update the export with the files currently
on it, and then calls recordExportUnderway. At that point, the
export.log records the export as "complete", but it's not really. And
that's fine. The same happens when using `git-annex export` when some
files are not available to send. Other repositories that have
access to the special remote can already retrieve files from it. As
the missing files get copied to the exported remote, all that needs
to be done is record each in the export db.

At this point, proxying to exporttree=yes annexobjects=yes special remotes
is fully working. Except for in the case where multiple files in the
tree use the same key, and the files are sent to the proxied remote
before pushing the tree.

It seems that even special remotes without annexobjects=yes will work if
used with the workflow where the git-annex branch is pushed before
copying files. But not with the `git-annex push` workflow.

Refresh standlone patch to avoid fuzz and offsets

remove unused imports

update

Merge branch 'master' into exportreeplus

fixed

Merge remote-tracking branch 'origin/master'

fix file corruption when proxying an upload to a special remote

The file corruption consists of each chunk of the file being duplicated.
Since chunks are typically a fixed size, it would certianly be possible
to get from a corrupted file back to the original file. But this is still
bad data loss.

Reversion was in commit fcc052bed81dac5a7664b815e3a3cf1ffb1b1659.
Luckily that did not make the most recent release.

proxying to exporttree=yes annexobjects=yes basically working

It works when using git-annex sync/push/assist, or when manually sending
all content to the proxied remote before pushing to the proxy remote.
But when the push comes before the content is sent, sending content does
not update the exported tree.

refine

finalized design for proxying to exporttree=yes annexobjects=yes special remotes

update

Added a comment: D: Correct

rename from annexobjects location on export

(When possible, of course it may not be there, or it may get renamed from
there for another exported file first. Or the remote may not support
renames.)

This will avoids redundant uploads.

An example case where this is important: Proxying to a exporttree remote,
a file is uploaded to it but is not yet in an exported tree. When the
exported tree is pushed, the remote needs to be updated by exporting to
it. In this case, the proxy doesn't have a copy of the file, so it would
need to download it from annexobjects before uploading it to the final
location. With this optimisation, it can just rename it.

However: If a key is used twice in an exported tree, it seems a proxy
will need to download and reupload anyway. Unless a copy operation is
added to exporttree remotes..

rename to annexobjects location on unexport

This avoids needing to re-upload the file again to get it to the
annexobjects location, which git-annex sync was doing when it was
preferred content.

If the file is not preferred content, sync will drop it from the
annexobjects location.

If the file has been deleted from the tree, it will remain in the
annexobjects location until an unused/dropunused pass is done.

update

Decided not to use the annexobjects location for exportTempName.

There doesn't seem to be any actual benefit to doing that, because an
export that renames to exportTempName always renames it back from that
to another location.

Also the annexobjects directory won't actually help with the paired
rename issue.

strong verification on retrieval from annexobjects location

The file in the annexobjects location may have been renamed from a
previously exported file that got deleted in a subsequent export.
Or it may be renamed to annexobjects temporarily before being renamed to
another name (to handle eg pairwise renames).

But, an exported file is not guaranteed to contain the content of the
key that the local repository last exported there. Another tree could
have been exported from elsewhere in the meantime.

So, files in annexobjects do not necessarily have the content of their
key. And so have to be strongly verified when retrieving. The same as
is done when retrieving exported files.

design work on annexobjects remotes

sync --content with annexobjects=true exporttree remotes

update

Merge branch 'master' into exportreeplus

in unexport, check for annexobjects presence before updating location log

The key may still be in the annexobjects location.

prevent removeKey from annexobjects=yes remote when the key is in the exported tree

Removing the key from the annexobjects location when it's in the
exported tree would leave it in the exported tree, and so succeeding
would update the location log incorrectly. But this also can't remove it
from the exported tree, because that would cause import tree to see a
file got deleted. So, refuse to remove in this situation.

It would be possible to remove from the annexobjects location and then
fail. Then if a key somehow got stored in both the annexobjects location
and the exported tree location(s), the duplicate would be resolved. Not
doing this because first, I don't know how that situation could happen,
and second, it seems wrong for a failed remove to have a side-effect
like that.

status

Remove debug output (to stderr)

Accidentially included in last version. Only happens when running code that
uses remoteUrl.

status

initial support for annexobjects=yes

Works but some commands may need changes to support special remotes
configured this way.

git-remote-annex: use annexLocationsBare

There was no good reason for it to be using annexLocationsNonBare,
and exporttree=yes annexobjects=yes is going to use annexLocationsBare,
so this should as well for consistency.

Since all returned ExportLocations are tried when retrieving objects,
this won't break backwards compatability.

removed

Added a comment: Necro

Added a comment: Necro

Added a comment

Added a comment

Added a comment: @joey

Avoid loading cluster log at startup

This fixes a problem with datalad's test suite, where loading the cluster
log happened to cause the git-annex branch commits to take a different
shape, with an additional commit.

It's also faster though, since many commands don't need the cluster log.

Just fill Annex.clusters with a thunk.

Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project

clean up build warnings when built w/o servant

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