Added a comment: Precise Workflow

Added a comment: Help with .nfsXXXX files

Added a comment

Added a comment

Added a comment: Remote Helper?

Added a comment

Added a comment

Added a comment: parameter  --from not accepted

Added a comment

Added a comment: Workaround: --force-small

Added a comment: Exact Moment Things Go Wrong

.md linting

Added a comment: Still a Problem (on Mac?)

Added a comment: Most servers upgraded to TLS v1.2 EMS / TLS v1.3

Added a comment

update

update

update

update

update for exporttree=yes

update

Merge branch 'exportreeplus'

add news item for git-annex 10.20240808

releasing package git-annex version 10.20240808

proxied importtree=yes remotes are untrustworthy

Even without exporttree=yes.

proxied exporttree=yes versionedexport=yes remotes are not untrusted

This removes versionedExport, which was only used by the S3 special
remote. Instead, versionedexport=yes is a common way for remotes to
indicate that they are versioned.

proxied exporttree=yes remotes are untrustworthy

This is not perfect because it does not handle versioned special
remotes, which should not be untrustworthy, but now are when proxied.

The implementation turned out to be easy, because the exporttree field
is a default field, so is available in RemoteConfig even for git
remotes.

update

update

update export db after rename from annexobjects location

This allows git-annex post-receive, on the first push to
the remote to see that it is able to get a key from it in
order to upload it back.

Also avoided actively checking if the source remote contains a key.
The location log is good enough. If the location log is wrong,
the export of that file will fail with an informative message.

post-receive: use the exporttree=yes remote as a source

This handles cases where a single key is used by multiple files in the
exported tree. When using `git-annex push`, the key's content gets
stored in the annexobjects location, and then when the branch is pushed,
it gets renamed from the annexobjects location to the first exported
file. For subsequent exported files, a copy of the content needs to be
made. This causes it to download the key from the remote in order to
upload another copy to it.

This is not needed when using `git push` followed by `git-annex copy --to`
the proxied remote, because the received key is stored at all export
locations then.

Also, fixed handling of the synced branch push, it was exporting master
when synced/master was pushed.

Note that currently, the first push to the remote does not see that it
is able to get a key from it in order to upload it back. It displays
"(not available)". The second push is able to. Since git-annex push
pushes first the synced branch and then the branch, this does end up
with a full export being made, but it is not quite right.

export: Added --from option

This is similar to git-annex copy --from --to, in that it downloads a
local copy, locks it for removal, uploads it, and drops it. Removal of
the temporary local copy is done without verifying numcopies for the
same reason as that command.

I do wonder, looking at this, if there's a race where the local copy
gets used as a copy to allow some other drop in the narrow window after
it is downloaded and before it gets locked for removal. That would need
some other repository to have an out of date location log that says the
repository contains a copy of the key, in order for it to try to use it
as a copy. If there is such a race, git-annex copy/move would also be
vulnerable to it. It would be better to lock it for removal before
starting to download it! That is possible in v10 repositories, which do
use a separate content lock file.

Note that, when the exported tree contains several files that use the
same key, it will be downloaded repeatedly, once per time needed to
upload it. It would be possible to avoid that extra work, but it would
complicate this since the local copy would need to be preserved, locked
for removal, until the end. Also, that would mean that interrupting the
export would leave possibly a lot of temporarily downloaded keys in the
local repository, while currently it can only leave one.

avoid warning in startDispose

When a file never got exported to the remote, and is now being removed
from the exported tree, it tried to rename, which failed, and displayed
an ugly warning:

unexport d m8
  rename failed (/home/joey/tmp/bench2/d/m8: renameFile:renamePath:rename: does not exist (No such file or directory)); deleting instead
ok

update proxied exporttree=yes remote on receive of sync branch

Since git-annex sync sends the sync branch first, and only displays the
output of the push to the sync branch, this makes git-annex
post-retrieve's output when updating the exported tree be visible when
syncing.

This also makes syncing with a non-bare repository still update the
exported tree, even when the checked out branch is not able to be
updated. The sync branch gets sent regardless.

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

comment

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.