Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

removed

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

add news item for git-annex 8.20201129

releasing package git-annex version 8.20201129

update to lts-16.27

update

close

improve tip

Merge branch 'master' of ssh://git-annex.branchable.com

update

tip for probably best use case for borg with git-annex

don't support dropping from thirdPartyPopulated for now

This code I'm reverting works. But it has a problem: The export db and
log and the ContentIdentifier db and log still list the content as being
stored in the remote. So when I ran borg create again and stored the
content in borg again in a new archive, git-annex sync noticed that, but
since it didn't update the tree for the old archives, it then thought
the content that had been removed from them was still in them, and so
git-annex get failed in an ugly way:

Include pattern 'tmp/x/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855' never matched.
[2020-12-28 16:40:44.878952393] process [933616] done ExitFailure 1

  user error (borg ["extract","/tmp/b::abs4","tmp/x/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"] exited 1)

It does not seem worth it to update the git tree for the export when dropping
content, that would make drop of many files very expensive in git tree objects
created. So, let's not support this I suppose..

support removing objects from borg

support removal from thirdPartyPopulated

also some other fixes to thirdPartyPopulated

borg appendonly config

revert recent lockContent change

lockContent should only be done when it's versioned

Bug report: annex.adjustedbranchrefresh ignored

move untrust forcing from Logs.Trust into Remote

No behavior changes here, but this is groundwork for letting remotes
such as borg vary untrust forcing depending on configuration.

simplify

adjustExportImport' is never called with both isexport and isimport False.

split off versionedExport from appendonly

S3 uses versionedExport, while GitLFS uses appendonly.

This is groundwork for later changes.

switch to createrepo_c

createrepo used python2 and got removed from debian

removed

generate more compact git-annex branch for imports

Especially from borg, where the content identifier logs
all end up being the same identical file!

But also, for other imports, the location tracking logs can,
in some cases, be identical files.

Bonus optimisation: Avoid looking up (and parsing when set)
GIT_ANNEX_VECTOR_CLOCK env var every time a log is written to.
Although the lookup does happen at startup even when no
log will be written now.

avoid grafting in an imported tree when it's not changed

This just avoids some churn in the git-annex branch.

graft in imported tree to avoid gc

Fix a bug that could prevent getting files from an importtree=yes remote,
because the imported tree was allowed to be garbage collected.

remove ContentIndentifiersCidRemoteIndex uniqueness constraint

For reasons explained in the bug report.

Implemented using a persistent migration, which works fine. It may add a
little startup overhead when a remote is enabled that uses this, but
probably un-noticable.

On the next major version, it would be fine to delete this database,
and regenerate it from the git-annex branch information. Then this
change could be reverted.

Did nothing about adding back the data that got dropped from the db
due to the bug. Only the borg special remote was probably affected,
and it's not been released yet. rm -rf .git/annex/cidsdb does work.

bug

avoid using export method when the remote only supports import

borg: add subdir= config

Note that, after changing it with enableremote, syncing won't rescan
known archives in the borg repo using the changed config. Probably not a
problem?

Also used File in some places where filenames that could theoretically
start with - are passed to borg, to avoid it confusing them with
options.

make sync --content get from third-party populated remotes like borg

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

todo

move unimplemented option to todo

merged borg

Still a couple related todos, but it's basically usable now.

Merge branch 'borg'

todo

implement retrieveExportWithContentIdentifier

Moved out an XXX to a todo

This seems about ready to merge..

borg can prompt

notice when an archive that was seen before gets deleted

implemented checkPresentExportWithContentIdentifier

todo

todo

optimisation for borg

Skip needing to list importable contents when unchanged since last time.

convert listImportableContents to throwing exceptions

avoid borg list of archives that have been listed before

This makes sync a lot faster in the common case where there's no new
backup.

There's still room for it to be faster. Currently the old imported tree
has to be traversed, to generate the ImportableContents. Which then
gets turned around to generate the new imported tree, which is
identical. So, it would be possible to just return a "no new imports",
or an ImportableContents that has a way to graft in a tree. The latter
is probably too far to go to optimise this, unless other things need it.
The former might be worth it, but it's already pretty fast, since git
ls-tree is pretty fast.

improve storage of redundant ContentIdentifiers

When a ContentIdentifier is already recorded, don't add it to the log
again, and avoid updating the log.

include borg archive name in tree, use empty ContentIdentifier

It's unusual to use a ContentIdentifier that is not semi-unique
for different contents. Note that in importKeys, it checks if a content
identifier is one that's known before, to avoid downloading the same
content twice. But that's done in a code path not used for borg repos,
because they are thirdpartypopulated.

notes on ImportableContents history not being used for retrieval

import from borg is basically working

Still some issues to deal with, see TODO and XXX.

Here's what gets logged, for each key:

cid log:
1608582045.832799227s 6720ebad-b20e-4460-a8f2-2477361aea75 !MjAyMC0xMi0yMVQxMTozMzoxNw==:!MjAyMC0xMi0yMVQxMzowNzoyNg==

The "!Mj" are base64 encoded borg archive names, since mine were
dates and contained some characters not allowed in cid logs unescaped.
There were archives that each contained the key. This list will grow as
more borg backups are done and learned about.

tree generated:
120000 blob 5ef6a4615c084819b44cd4e3a31657664ddf643b x/dotgit/annex/objects/06/mv/SHA256E-s30--a5d8532e64ec28f5491e25e7a6c1cb68f80507c1be6c1b35f8ec53d25413e5da/SHA256E-s30--a5d8532e64ec28f5491e25e7a6c1cb68f80507c1be6c1b35f8ec53d25413e5da
120000 blob 063a139d3021c8db60f5c576d29fada2b824d91c x/dotgit/annex/objects/72/PP/SHA256E-s30--e80b09a854b4e4d99a76caaa6983b34272480e0b4fdb95d04234a54b4849b893/SHA256E-s30--e80b09a854b4e4d99a76caaa6983b34272480e0b4fdb95d04234a54b4849b893
120000 blob b53b54916fd6abf21fedf796deca08d5ac7a75af x/dotgit/annex/objects/Ww/pk/SHA256E-s30--6aac072a8ebf02a5807c4f15e77ed585a6c87b3b333ba625a3c8d6b4dc50a9f2/SHA256E-s30--6aac072a8ebf02a5807c4f15e77ed585a6c87b3b333ba625a3c8d6b4dc50a9f2

This commit was sponsored by Denis Dzyubenko on Patreon.

improve thirdpartypopulated support

May actually work now.

Note that, importKey now has to add the size to the key if it's supposed
to have size. Remote.Directory relied on the importer adding the size,
which is no longer done, so it was changed; it was the only one.
This way, importKey does not need to behave differently between regular
and thirdpartypopulated imports.

Added a comment: well done!

support thirdPartyPopulated

These don't have importTree in their config, because they don't support
tree import, but they do still support import, and do not support export
or key/value modification.

fix logic error in thirdPartyPopulated handling

Added a comment: "mirror" workflow: usage of "wanted" expression is inconsistent with regular annex remote

Added a comment: adb special remote

bug report

refactor

That code was not borg specific, and I can see making more remotes for
other backup software.

started borg special remote

Still need to implement 3 methods, but importKeyM looks like it will
work well to find annex object files.

Merge branch 'master' into borg

build fix

start borg special remote

Compiles, but unusable so far.

Merge branch 'master' into borg

add thirdPartyPopulated interface

This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.

So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that  the tree is recorded in the export log, and gets grafted
into the git-annex branch.

importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.

It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.

Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.

(Untested and unused as of yet.)

This commit was sponsored by Jochen Bartl on Patreon.

Merge branch 'master' of ssh://git-annex.branchable.com

fix handling of importtree-only remotes

Don't want to try to use these remotes as key/value remotes, which will
surely fail. It only recently became possible for importtree to be set
w/o exporttree, so before this code was ok.

(cherry picked from commit 97599cb0f7f4115aa5a3e81a91ee3d1d6c52dc84)

update

change info from export=yes to exporttree=yes and same for import

for consistency

Added a comment: encryption=onlycreds

Merge branch 'master' into borg

avoid redundant set of a S3 verison ID that is already recorded

I think this could cause unnecessary changes to the git-annex branch,
and retrieveExportWithContentIdentifier is now also used for getting
content from importtree=yes remotes, so it would happen more frequently
so let's avoid.

Merge branch 'master' into borg

Merge branch 'master' of ssh://git-annex.branchable.com

todo

update warnExportImportConflict for import-only remotes

fix call to warnExportImportConflict

That needs a Remote that has the right export/import set up, not the input
Remote, which does not yet.

add missing space

import remotes use ContentIdentifier for getting and checking content

This is better than using the equivilant actions for export remotes,
especially for getting content, since the ContentIdentifier checking
means we can be sure (enough) that the content is valid to not force
verification of content. Which allows getting keys of types that cannot
be verified.

Also, reorganized the internals of adjustExportImport which was becoming
very hard to follow. Now it's clear what each method does in each case.

force verification after getting file from export remote

This way, if annex.verify is disabled, it's still checked, since this is
not a key/value store, it has to be checked.

Added a comment

refactor common code